From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "paul rivers" <rivers(dot)paul(at)gmail(dot)com> |
Cc: | "Ivan Sergio Borgonovo" <mail(at)webthatworks(dot)it>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: SQL injection, php and queueing multiple statement |
Date: | 2008-04-12 19:25:36 |
Message-ID: | 87zlrydgen.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"paul rivers" <rivers(dot)paul(at)gmail(dot)com> writes:
>> If I can't, and I doubt there is a system that will let me enforce
>> that policy at a reasonable cost, why not providing a safety net that
>> will at least raise the bar for the attacker at a very cheap cost?
>
> How do you do this? Disallow string concatenation and/or variable interpolation
> for any string that's going to be shipped off to the database?
Actually there is a system that can do this. Perl with the -T option. It keeps
track of which strings are "tainted" by user-input and functions like eval
will cause errors if you try to pass them a tainted string. The database
drivers support this and will trigger an error if they're passed a tainted
string.
It doesn't protect you from a malicious programmer of course. It's easy to
intentionally untaint a string. But it does a pretty good job of protecting
you against accidental security holes.
In my experience if you have a flat policy of _never_ allowing interpolated
strings then the problem just doesn't come up. It's easy to spot interpolated
strings during code review. If you have a more complex policy where sometimes
they're allowed if they come from internal data structures or they've been
checked then I think it would be helpful.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
From | Date | Subject | |
---|---|---|---|
Next Message | paul rivers | 2008-04-12 19:29:29 | Re: SQL injection, php and queueing multiple statement |
Previous Message | Peter Wilson | 2008-04-12 19:13:56 | Re: SQL injection, php and queueing multiple statement |