Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL.com compromised via (guess what?) SQL injection

blog.sucuri.net

Post reply on HN
Print view View original

31–40 of 117 posts

Re: MySQL.com compromised via (guess what?) SQL injection

#31

Post by nupark »

FooBarWidget wrote: post #20
kprobst wrote: post #15

Earlier quoted context omitted.

The database in this case has to share some of the blame. For years MySQL did not support parametrized queries or stored procedures (or did not promote them), and many of the people coding against it consistently claimed that they didn't need that kind of "enterprise crap" polluting their favorite DB. This gave way to a MASSIVE code base that is inherently vulnerable to injection attacks. So yeah, it's the fault of t…

You don't need parameterized queries or stored procedures for protection against injection. In fact they're not injection protection mechanisms at all. What you actually mean is that the database libraries should provide parameterized-style APIs. There's no need for the database's native wire protocol to explicitly support parameterization to implement this. For example Ruby on Rails's ActiveRecord provides an API th…

> You don't need parameterized queries or stored procedures for protection against injection ... There's no need for the database's native wire protocol to explicitly support parameterization to implement this.

This means that every protocol client must implement their own query escaping, rather than relying on the database to provide a single, normative implementation of escaping.

> For example Ruby on Rails's ActiveRecord provides an API that looks a lot like it uses parameterization under the hood:

ActiveRecord's use of the non-parameterized APIs has led to a number of escaping/injection issues in the past eg, (http://www.ruby-forum.com/topic/152058, http://gsa.ca.com/vulninfo/vuln.aspx?id=36929, etc).

> If you think stored procedures protect you against SQL injection, consider the following code snippet ...

I believe the original poster was referring to the use of stored procedures as a mechanism for preventing or discouraging unintended direct modification of the database by applications, rather than SQL injection, specifically.

Re: MySQL.com compromised via (guess what?) SQL injection

#32

Post by tptacek »

awj wrote: post #25
FooBarWidget wrote: post #20

Earlier quoted context omitted.

You don't need parameterized queries or stored procedures for protection against injection. In fact they're not injection protection mechanisms at all. What you actually mean is that the database libraries should provide parameterized-style APIs. There's no need for the database's native wire protocol to explicitly support parameterization to implement this. For example Ruby on Rails's ActiveRecord provides an API th…

You're arguing against the periphery of his point. By waiting so long to provide parameterized queries, MySQL helped foster the attitude that they were "useless enterprise bloat". The lack of parameterized queries was likely an influencing factor in the non-support or non-advertisement of parameterized-style APIs. MySQL is a crucial part of its own community. You cannot hold the community responsible for this situati…

I have never heard someone say parameterized queries were "useless enterprise bloat". Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test. Your reaction here sounds hyperbolic, and the parent commenter is right: parameterized queries, while helpful, are neither required nor sufficient for defense against SQLI.

Re: MySQL.com compromised via (guess what?) SQL injection

#34

Post by sausagefeet »

xd wrote: post #21
riffraff wrote: post #2

while I understand that sql injection is mostly a fault of the host programming language/developer (php in this case) and not of the dbms/dba, couldn't the latter have avoided this in part by limiting user privileges so that it was impossible to "list the internal databases, tables and password dump" e.g. "REVOKE SHOW DATABASES, SHOW VIEW" ? (I'm aware this may make impossible to use some web frameworks which rely on…

Sorry, but how is PHP at fault? You can shoot yourself in the foot with ANY programming language.

In a language like Ocaml or Haskell a SQL library can make it impossible to query the DB with unsanitized queries.

Re: MySQL.com compromised via (guess what?) SQL injection

#35

Post by tptacek »

nupark wrote: post #31
FooBarWidget wrote: post #20

Earlier quoted context omitted.

You don't need parameterized queries or stored procedures for protection against injection. In fact they're not injection protection mechanisms at all. What you actually mean is that the database libraries should provide parameterized-style APIs. There's no need for the database's native wire protocol to explicitly support parameterization to implement this. For example Ruby on Rails's ActiveRecord provides an API th…

> You don't need parameterized queries or stored procedures for protection against injection ... There's no need for the database's native wire protocol to explicitly support parameterization to implement this. This means that every protocol client must implement their own query escaping, rather than relying on the database to provide a single, normative implementation of escaping. > For example Ruby on Rails's Activ…

It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue.

The examples you've provided of Rails SQLI issues are bad ones:

* The first is a discussion of SQLI in an interface designed to accept raw SQL; it's the ActiveRecord "back door" interface.

* The second is a discussion of SQLI in a context where parameterized queries don't work anyways (the MySQL protocol doesn't accept LIMIT and OFFSET arguments as anything but integer constants); it is also the simplest of the class of SQLI concern areas (you can solve it by blindly calling #to_i on your inputs), which also includes table names, sort orders, and column references.

Re: MySQL.com compromised via (guess what?) SQL injection

#36

Post by tptacek »

xd wrote: post #10
albertzeyer wrote: post #4

I wonder a bit that there isn't a real binary protocol for SQL. Edit: It seems there are ways to work around server-side SQL parsing: http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-pa... I was thinking more about why it is allowed at all to send text-like SQL queries to a server. A binary protocol would both be simpler to handle and would have saved us from a lot of trouble. Edit: If all client-side libs (…

Reply to your edit. SQL is text. Also no one is sending a query to the server. It's a value that is embedded into the SQL query that circumvents it.

I don't understand this (or, to be honest, the parent). MySQL has a binary protocol. The MySQL binary protocol does, in fact, allow you to parse a query template and use it in subsequent calls with bound variables; that's how "parameterized queries" work.

Re: MySQL.com compromised via (guess what?) SQL injection

#37

Post by nupark »

tptacek wrote: post #32
awj wrote: post #25

Earlier quoted context omitted.

You're arguing against the periphery of his point. By waiting so long to provide parameterized queries, MySQL helped foster the attitude that they were "useless enterprise bloat". The lack of parameterized queries was likely an influencing factor in the non-support or non-advertisement of parameterized-style APIs. MySQL is a crucial part of its own community. You cannot hold the community responsible for this situati…

I have never heard someone say parameterized queries were "useless enterprise bloat". Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test. Your reaction here sounds hyperbolic, and the parent commenter is right: parameterized queries, while helpful, are neither required nor sufficient for defense against SQLI.

Could you expand a bit on how parameterized queries are not sufficient for defense against SQL injection (assuming, of course, that developers use the escaping and do not concatenate unescaped data into queries)?

As for them being required -- you can obviously escape queries yourself, but the normative reference for escaping is the target database itself, and reproducing escaping locally in the client brings with it the likelihood of introducing an error in the custom implementation.

Re: MySQL.com compromised via (guess what?) SQL injection

#38

Post by tptacek »

xd wrote: post #18
albertzeyer wrote: post #4

I wonder a bit that there isn't a real binary protocol for SQL. Edit: It seems there are ways to work around server-side SQL parsing: http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-pa... I was thinking more about why it is allowed at all to send text-like SQL queries to a server. A binary protocol would both be simpler to handle and would have saved us from a lot of trouble. Edit: If all client-side libs (…

Reply to your further edit (let't hope this is the last one ;) Prepared statements should afford you a clean conscience because the values never make up part of the SQL query .. unless you are using a library that emulates it, and there are libraries out there that do, so don't assume anything.

Prepared statements do not afford you a "clean conscience". You still need to be careful with your inputs in parameterized queries, because not every input to every query can be bound as a variable. Some operations do require dynamic query construction.

Re: MySQL.com compromised via (guess what?) SQL injection

#40

Post by tptacek »

nupark wrote: post #37
tptacek wrote: post #32

Earlier quoted context omitted.

I have never heard someone say parameterized queries were "useless enterprise bloat". Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test. Your reaction here sounds hyperbolic, and the parent commenter is right: parameterized queries, while helpful, are neither required nor sufficient for defense against SQLI.

Could you expand a bit on how parameterized queries are not sufficient for defense against SQL injection (assuming, of course, that developers use the escaping and do not concatenate unescaped data into queries)? As for them being required -- you can obviously escape queries yourself, but the normative reference for escaping is the target database itself, and reproducing escaping locally in the client brings with it…

Not every "input" to a "query" (using these terms loosely) can be bound as a variable. Simple example: ASC and DESC. There are trickier examples that are still common.

It is a bad idea for applications to implement quoting regimes, and it is a bad idea for frameworks to try to create one-size-fits-all quoting regimes like PHP used to. That doesn't mean it's a bad idea for a framework's e.g. MySQL support to provide the capability of sanitizing MySQL inputs under a common database API.

Post reply on HN