Re: Protection from SQL injection

Поиск
Список
Период
Сортировка
От Darren Reed
Тема Re: Protection from SQL injection
Дата
Msg-id 481F2F1B.8080605@fastmail.net
обсуждение исходный текст
Ответ на Re: Protection from SQL injection  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Protection from SQL injection  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-hackers
Tom Lane wrote:
> Darren Reed <darrenr@fastmail.net> writes:
>   
>> This might seem sillly, but...
>> ...are comments going to be considered statements for the purpose of 
>> this knob?
>> (hoping the anwer is "yes")
>>     
>
> Are you trying to say we should forbid comments?  No thank you.
>   

No.

When psql (for example) parses this:
COMMIT;BEGIN;-- Hi
it will generate individual commands with postgres (the server) over
the connection.  ie. psql sends "COMMIT;" waits, then sends 'BEGIN;",
waits, etc.

When you do this in perl:
$db->prepare("COMMIT;BEGIN;--");
one single command string (the entire string above) is sent to the server.

How often do people code comments into prepare statements in perl
or the equivalent in java, ruby, etc?

Do you put comments in your perl prepare statements?

If comments count as a statement, at the server end, then the 
multi-statement
disabling also disables another attack vector - slightly: you can no 
longer attack
using this as your username:"' OR 1=1;--"

This raises another point - preventing muilti-statement attacks work so
long as the "hacker string" isn't broken up into multiple statements by the
client side.  Passing said string to /bin/sh, which then passes it to psql
would successfully enable the attack even with this knob turned on.  But
few people are likely to be using a design that is that slow.

Darren



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: Protection from SQL injection
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Protection from SQL injection