3 ms·

> user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack

by venus 14y ago

> user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack How do you implement authentication if you can't check an email (user provided data) matches a password (user provided data, probably hashed but still)? How do you look up blog posts by a user-provided tag, without using that tag in query composition? How do you save any user provided information at all without somehow including that information in an SQL query? You have to use escaped user provided data all the time in a real application. Any actual web developer would know that.

numbsafari 14y ago
Simple: use parametric prepared statements instead of composing a SQL string with the user-provided data (escaped or otherwise). This has been available in numerous database APIs for like, ever. For example [1], [2], [3]. Any actual web developer will have read something along the lines of [4]. A lot people seem confused by my original post, which was in response to a Django user's question about how this sort of thing happens. I provided a general response which seems to have offended some people. Yes, Rails does appear to use parameterized statements. However, when it is building those parameterized statements it's still using user provided data to build the SQL. If that weren't the case, then this wouldn't be a bug at all, would it? Of course not, so obviously it is using user-provided data in some way, otherwise an HTTP cookie's value wouldn't be getting passed to the database, would it? The prepared statement string shouldn't be composed with anything user provided. [1] http://php.net/manual/en/mysqli-stmt.bind-param.php http://php.net/manual/en/mysqli-stmt.bind-param.php [2] http://bit.ly/WlPEFR http://bit.ly/WlPEFR [3] http://rubydoc.info/gems/mysql/2.9.0/Mysql/Stmt http://rubydoc.info/gems/mysql/2.9.0/Mysql/Stmt [4] https://www.owasp.org/index.php/Top_10_2010-A1 https://www.owasp.org/index.php/Top_10_2010-A1
- cdcarter 14y ago
  The attack is targeting a secondary method signature that #find_by_* can hold with the express purpose of executing arbitrary SQL. That is, when #find_by_* is invoked with a hash with a key such as :select or :conditions it expects a SQL string, probably hard coded. The bug however is that it's possible for user input, with a session hijacking, to provide that hash with symbolic key. There is no SQL injection, this is straight up arbitrary execution of SQL.
  - numbsafari 14y ago
    Out of curiosity, all other debates aside, would it not be helpful to have (either built-in or as a separate plugin) a way for Rails to run a simple set of sanity checks on the SQL it passes to the DB server? For example, checking to make sure that the generated SQL doesn't contain "--" wouldn't fix the underlying problem, but it could be used to prevent the exploit from ultimately working (and, if someone tried this, would alert you to that fact, assuming the error was logged). I get that this would create some performance overhead, so it would ideally be configurable.

by venus 14y ago

numbsafari 14y ago

Simple: use parametric prepared statements instead of composing a SQL string with the user-provided data (escaped or otherwise). This has been available in numerous database APIs for like, ever. For example [1], [2], [3]. Any actual web developer will have read something along the lines of [4]. A lot people seem confused by my original post, which was in response to a Django user's question about how this sort of thing happens. I provided a general response which seems to have offended some people. Yes, Rails does appear to use parameterized statements. However, when it is building those parameterized statements it's still using user provided data to build the SQL. If that weren't the case, then this wouldn't be a bug at all, would it? Of course not, so obviously it is using user-provided data in some way, otherwise an HTTP cookie's value wouldn't be getting passed to the database, would it? The prepared statement string shouldn't be composed with anything user provided. [1] http://php.net/manual/en/mysqli-stmt.bind-param.php http://php.net/manual/en/mysqli-stmt.bind-param.php [2] http://bit.ly/WlPEFR http://bit.ly/WlPEFR [3] http://rubydoc.info/gems/mysql/2.9.0/Mysql/Stmt http://rubydoc.info/gems/mysql/2.9.0/Mysql/Stmt [4] https://www.owasp.org/index.php/Top_10_2010-A1 https://www.owasp.org/index.php/Top_10_2010-A1

cdcarter 14y ago
The attack is targeting a secondary method signature that #find_by_* can hold with the express purpose of executing arbitrary SQL. That is, when #find_by_* is invoked with a hash with a key such as :select or :conditions it expects a SQL string, probably hard coded. The bug however is that it's possible for user input, with a session hijacking, to provide that hash with symbolic key. There is no SQL injection, this is straight up arbitrary execution of SQL.
- numbsafari 14y ago
  Out of curiosity, all other debates aside, would it not be helpful to have (either built-in or as a separate plugin) a way for Rails to run a simple set of sanity checks on the SQL it passes to the DB server? For example, checking to make sure that the generated SQL doesn't contain "--" wouldn't fix the underlying problem, but it could be used to prevent the exploit from ultimately working (and, if someone tried this, would alert you to that fact, assuming the error was logged). I get that this would create some performance overhead, so it would ideally be configurable.