Re: Protection from SQL injection
От | Darren Reed |
---|---|
Тема | Re: Protection from SQL injection |
Дата | |
Msg-id | 481B2047.9090505@fastmail.net обсуждение исходный текст |
Ответ на | Protection from SQL injection ("Thomas Mueller" <thomas.tom.mueller@gmail.com>) |
Ответы |
Re: Protection from SQL injection
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Protection from SQL injection (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
**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
В списке pgsql-hackers по дате отправления: