From: | paul rivers <rivers(dot)paul(at)gmail(dot)com> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(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:29:29 |
Message-ID: | 48010D99.1040309@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Gregory Stark wrote:
> "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.
>
>
Good point. What happens in the case I query a string from the database,
and use this result to build another sql string via concatenation?
Assume the value in the database came from user input, albeit via
another source and not this script. Will taint catch this? (Genuine
question - I don't know.)
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-04-12 19:33:04 | Re: Postgres on shared network drive |
Previous Message | Gregory Stark | 2008-04-12 19:25:36 | Re: SQL injection, php and queueing multiple statement |