Re: [GENERAL] Prepared statement performance...

From: Toby <toby(at)paperjet(dot)com>
To: <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: [GENERAL] Prepared statement performance...
Date: 2002-10-14 09:47:16
Message-ID: 5.1.0.14.0.20021014101648.00af8360@mail.flirble.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Kovacs 2002-10-14 10:03:05 Re: [GENERAL] Prepared statement performance...
Previous Message nferrier 2002-10-14 09:20:37 Re: [GENERAL] Prepared statement performance...

Browse pgsql-jdbc by date

  From Date Subject
Next Message Peter Kovacs 2002-10-14 10:03:05 Re: [GENERAL] Prepared statement performance...
Previous Message nferrier 2002-10-14 09:20:37 Re: [GENERAL] Prepared statement performance...