Re: Protection from SQL injection - Mailing list pgsql-hackers

From Darren Reed
Subject Re: Protection from SQL injection
Date
Msg-id 481F2F1B.8080605@fastmail.net
Whole thread Raw
In response to Re: Protection from SQL injection  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Protection from SQL injection  ("Greg Sabino Mullane" <greg@turnstep.com>)
List 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 by date:

Previous
From: Chris Browne
Date:
Subject: Re: Protection from SQL injection
Next
From: Andrew Dunstan
Date:
Subject: Re: Protection from SQL injection