Re: Protection from SQL injection

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