3 ms·

For protection against sql injection, I'd recommend taking a look at Meredith Patterson's Libdejector http://sourceforge.net/project/showfiles.php?group_id=1450

For protection against sql injection, I'd recommend taking a look at Meredith Patterson's Libdejector http://sourceforge.net/project/showfiles.php?group_id=145075 http://sourceforge.net/project/showfiles.php?group_id=145075 A partial presentation on it is here: http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-hansen.pdf http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-han... It works by having the user offer an exemplar of a dynamic query and then verifying that the actual query is limited to the syntactic forms seen in the exemplar.

tptacek 18y ago
This is the kind of thing you deploy when you didn't write the app. You can implement it easily for Rails apps by proxying MySQL network connections and parsing the queries. If you can write a lexer, you can catch 99% of attacks just by counting terminals. It's not the right idea, at all, for development teams. The reason is, parameterized queries solve this problem. If you're parsing queries before you bind parameters, you're not injectable. Audit your code to ensure you're using stored procedures. Audit your inputs to make sure they aren't passing things like "DESC" and "ASC" when they should be passing "down" and "up", which you can't fuck up. Then stop thinking about that problem. Move on to a more important problem, which everyone ignores: locking down your database connection. Why does the (one) database connection in WordPress have rights to insert into "wp_users"? A much better area to spend your time in.
- rcoder 18y ago
  I agree 100% with the assertion that modern webapps should divide privileges across multiple database connections/security principals. A large portion of SQL injection and session-hijacking issues could be rendered useless overnight if the basic tenet of "minimal privilege" were taken to heart by LAMP coders.
- bayareaguy 18y ago
  For MySQL you can use the excellent http://forge.mysql.com/wiki/MySQL_Proxy http://forge.mysql.com/wiki/MySQL_Proxy in just this way. However didn't the Remote Agent bug story posted here recently reveal the weakness in relying on auditing? A bug identified by a formal verifier was accidentally re-introduced later in development after they "stopped thinking about the problem".

tptacek 18y ago

This is the kind of thing you deploy when you didn't write the app. You can implement it easily for Rails apps by proxying MySQL network connections and parsing the queries. If you can write a lexer, you can catch 99% of attacks just by counting terminals. It's not the right idea, at all, for development teams. The reason is, parameterized queries solve this problem. If you're parsing queries before you bind parameters, you're not injectable. Audit your code to ensure you're using stored procedures. Audit your inputs to make sure they aren't passing things like "DESC" and "ASC" when they should be passing "down" and "up", which you can't fuck up. Then stop thinking about that problem. Move on to a more important problem, which everyone ignores: locking down your database connection. Why does the (one) database connection in WordPress have rights to insert into "wp_users"? A much better area to spend your time in.

rcoder 18y ago
I agree 100% with the assertion that modern webapps should divide privileges across multiple database connections/security principals. A large portion of SQL injection and session-hijacking issues could be rendered useless overnight if the basic tenet of "minimal privilege" were taken to heart by LAMP coders.
bayareaguy 18y ago
For MySQL you can use the excellent http://forge.mysql.com/wiki/MySQL_Proxy http://forge.mysql.com/wiki/MySQL_Proxy in just this way. However didn't the Remote Agent bug story posted here recently reveal the weakness in relying on auditing? A bug identified by a formal verifier was accidentally re-introduced later in development after they "stopped thinking about the problem".