From: | nferrier(at)tapsellferrier(dot)co(dot)uk |
---|---|
To: | "Peter Kovacs" <peter(dot)kovacs(at)sysdata(dot)siemens(dot)hu> |
Cc: | <pgsql-jdbc(at)postgresql(dot)org>, "Toby" <toby(at)paperjet(dot)com> |
Subject: | Re: [GENERAL] Prepared statement performance... |
Date: | 2002-10-14 09:20:37 |
Message-ID: | ur8etpeai.fsf@tapsellferrier.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-jdbc |
"Peter Kovacs" <peter(dot)kovacs(at)sysdata(dot)siemens(dot)hu> writes:
> Thank you for your explanation. But I still do not see how
> > INSERT INTO Users (username) VALUES ('joe'; DROP TABLE users');
> will be evaluated so that it drops table 'users'. Actually, this should
> evaluate to a syntax error, shouldn't it?
That's right. I think toby is mistaking the classic javascript hack
for a SQL hack.
The JS hack is possible because developers rarely use strong
validation for input fields, thus allowing JS statements into the
database. When these are presented on webpages they can get up to all
sorts of tricks and wheezes.
I've never heard of a SQL hack based on input fields, it seems most
unlikely but something could probably be done based on stored procs,
the hacker would have to have intimiate knowledge of the stored procs
and would also have to find one that would do something dangerous.
Nic
From | Date | Subject | |
---|---|---|---|
Next Message | Toby | 2002-10-14 09:47:16 | Re: [GENERAL] Prepared statement performance... |
Previous Message | Peter Kovacs | 2002-10-14 09:05:01 | Re: [GENERAL] Prepared statement performance... |
From | Date | Subject | |
---|---|---|---|
Next Message | Toby | 2002-10-14 09:47:16 | Re: [GENERAL] Prepared statement performance... |
Previous Message | Peter Kovacs | 2002-10-14 09:05:01 | Re: [GENERAL] Prepared statement performance... |