Re: Protection from SQL injection

**Andrew Sullivan wrote:
> On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote:
>
> > But it's true that preventing multi-statements adds a layer of
> > idiot-proofness... a rather thin layer...
>
> As I already said in a previous remark in this thread, I don't really
> like partial security solutions.
>
> What the "no multi-statement SQL" switch adds is a complete protection
> against _one class_ of injection attacks. What is nice about it is
> that it completely eliminates that class of attacks, so they are no
> longer something one needs to worry about.
>
> They do not, of course, prevent every kind of injection attack. I
> think the thread has already had ample evidence that such complete
> prevention is either impractical to implement, too costly to existing
> applications, too limiting, not actually effective (i.e. not really
> complete prevention), or some combination of the above.
>
> That's not an argument that the simple change that is effective for
> only one class of attacks is a bad idea. Making the battlefield
> smaller is one thing one can do to decrease one's exposure to attack.

Andrew, Tom, please just add this feature and let those who don't
like it just send their complains to /dev/null. To be honest, I'm
surprised it has not appeared sooner...I was thinking of hacking
on postgres to implement it then I found this thread. I've already
started looking at writing a proxy for postgres with the first
important task to be converting multiple statements in the SQL TCP
data stream to a series of spaces...for those that can't upgrade
to a version where they can turn such a knob on.

Also, I think the "no-multistatement SQL" should default to on.

Why?

Because interacting with the database is always through an action
that you do and if you're being half way intelligent about it, you
are always checking that each action succeeded before going on to
the next.

I think one of the more important exercises is to examine PHP and
see if it bundles up any statements into more than one call to
prepare or execute in perl.

As with all security solutions, the end result is made up of many
layers, there is rarely just one big gate. The more layers we have,
regardless of how thick or thing they are, the better equipped we
are to deal with attacks.

Cheers,
Darren