Re: [GENERAL] Prepared statement performance... - Mailing list pgsql-jdbc

From Toby
Subject Re: [GENERAL] Prepared statement performance...
Date
Msg-id 5.1.0.14.0.20021014101648.00af8360@mail.flirble.org
Whole thread Raw
In response to Re: [GENERAL] Prepared statement performance...  ("Peter Kovacs" <peter.kovacs@sysdata.siemens.hu>)
Responses Re: [GENERAL] Prepared statement performance...  (nferrier@tapsellferrier.co.uk)
List 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 by date:

Previous
From: nferrier@tapsellferrier.co.uk
Date:
Subject: Re: [GENERAL] Prepared statement performance...
Next
From: "Peter Kovacs"
Date:
Subject: Re: [GENERAL] Prepared statement performance...