Re: Protection from SQL injection

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

In response to

Responses

Browse pgsql-hackers by date

  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