From: | Darren Reed <darrenr(at)fastmail(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | ajs(at)commandprompt(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Protection from SQL injection |
Date: | 2008-05-05 16:00:27 |
Message-ID: | 481F2F1B.8080605@fastmail.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Darren Reed <darrenr(at)fastmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-05-05 18:00:30 | Re: Protection from SQL injection |
Previous Message | Chris Browne | 2008-05-05 14:28:12 | Re: Protection from SQL injection |