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
|
Список | 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 по дате отправления: