Re: [GENERAL] Prepared statement performance...
От | Toby |
---|---|
Тема | Re: [GENERAL] Prepared statement performance... |
Дата | |
Msg-id | 5.1.0.14.0.20021014101648.00af8360@mail.flirble.org обсуждение исходный текст |
Ответ на | Re: [GENERAL] Prepared statement performance... ("Peter Kovacs" <peter.kovacs@sysdata.siemens.hu>) |
Ответы |
Re: [GENERAL] Prepared statement performance...
|
Список | pgsql-jdbc |
At 11:05 14/10/2002 +0200, Peter Kovacs wrote: > >will be evaluated so that it drops table 'users'. Actually, this should > >evaluate to a syntax error, shouldn't it? well, as my explanation noted > > INSERT INTO Users (username) VALUES ('joe'; DROP TABLE users'); > > > > This might cause the users table to be dropped. Not entirely sure if the > > above would actually do this, but a little bit of mucking about with what > > you type into the FORM field would certainly do this. the point being that a string containing an SQL command sent to the backend can contain several statements, like the above. the more i look at it, the more i agree that the above would throw a syntax error. however, if there was a ; after the table name, users, then then the resultant SQL would be INSERT INTO Users (username) VALUES ('joe'; DROP TABLE users;'); i suspect this would work. I don't see how the above is a classic javascript hack, since there's no javascript. i've seen on production code places where strings taken from form fields are stored in cookies and session variables and subsequently written directly to the database, as shown above. i've been to sites where this is possible and it also does not require intimate knowledge of the target database. a bit of messing around will often cause errors to be thrown and, unless the target webserver is configured appropriately (IIS is good for this), it is often possible to see the detailed error message...whihc itself can show hints of the backend structure. by way of example, try going to http://www.westmisnter.ac.uk/ and in one of the search boxes enter the following ';select * from msdb..sysjobs; Now then, if someone spent a few minutes working on this, I'm sure it would be possible to drop a table or 2 or, at the very least, trash a load of data. the same will be possible on a postgres backend. course, what this has to do with performance I don't know. toby
В списке pgsql-jdbc по дате отправления: