Re: SQL injection, php and queueing multiple statement
От | Gregory Stark |
---|---|
Тема | Re: SQL injection, php and queueing multiple statement |
Дата | |
Msg-id | 87zlrydgen.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: SQL injection, php and queueing multiple statement (paul rivers <rivers.paul@gmail.com>) |
Ответы |
Re: SQL injection, php and queueing multiple statement
Re: SQL injection, php and queueing multiple statement |
Список | pgsql-general |
"paul rivers" <rivers.paul@gmail.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!
В списке pgsql-general по дате отправления: