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

From Thomas Mueller
Subject Re: Protection from SQL injection
Date
Msg-id 5f211bd50805011000hf86f10cyc26dc51cb52c0c1e@mail.gmail.com
Whole thread Raw
In response to Re: Protection from SQL injection  (Andrew Sullivan <ajs@commandprompt.com>)
Responses Re: Protection from SQL injection  (Andrew Dunstan <andrew@dunslane.net>)
Re: Protection from SQL injection  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

> disallow more than one SQL statement per PQexec.

I agree, it would help.

>  1. Inexpensive to implement

Disabling literals wouldn't be much harder to implement I believe, but
I don't know the PostgreSQL internals.

>  2. Unlikely to break most applications;

That's true.

>  3. Closes off a fairly large class of injection attacks.

Unfortunately, it doesn't prevent SQL injection at all. Yes, updating
and deleting data is harder (if the SQL injection is on a SELECT), but
if an attacker only wants to destroy something he could use SETVAL.
There is almost zero protection from reading data (no matter where the
SQL injection is). It is quite simple to write an automated tool that
downloads the whole database contents (first the catalog, and then all
the data). Downloading the data would be a bit slower if the SQL
injection is in the WHERE clause. Actually, it would be quite fun to
write a generic tool ;-) Tools are usually used by the script kiddies.
My website was once hacked by a 14 year old boy. He used a tool that
read the admin password via SQL injection.

Disabling literals is still the only way to actually protect from SQL
injection. Except Meredith's libdejector, which is even a bit better
as far as I see, but requires more work from the developer. I don't
count Microsoft LINQ (or Java Quaere) currently because that would
require a complete re-write of the application.

Regards,
Thomas


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Let the commit fest begin!
Next
From: KaiGai Kohei
Date:
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches