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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
