Thank you. So I think herewith we made pointless the original arguement Curt
Sampson made in his mail in support Barry's twisted interpretation of
PreparedStatement.
Peter
PS:
When I am travelling in Budapest (capital of Hungary, my country) on the
bus, and some exhausted poor elderly tries to sheepishly argument with some
youngsters occupying recklessly the last seat in the bus leaving the elderly
standing, I always tempted to cynically tell the upset elderly: "This public
transport my lady. If you wish first class service, you should take a taxi."
Of course, I never say this, because it would be a sign of very bad taste.
But I often giving *myself* this kind of rebuff when I am surfing on open
source mailing lists and find people saying this and that without giving a
shit to think about it first or --more importantly-- to think about the
context they're making their remarks: "My dear, this is public transport,
worth the money you pay for it."
The above was meant to be humorous.
----- Original Message -----
From: <nferrier@tapsellferrier.co.uk>
To: "Peter Kovacs" <peter.kovacs@sysdata.siemens.hu>
Cc: <pgsql-jdbc@postgresql.org>; "Toby" <toby@paperjet.com>
Sent: Monday, October 14, 2002 11:20 AM
Subject: Re: [JDBC] [GENERAL] Prepared statement performance...
> "Peter Kovacs" <peter.kovacs@sysdata.siemens.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
>
