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

61–70 of 117 posts

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

#61

Post by [deleted] »

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…

[deleted]

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

#62

Post by Groxx »

mattmanser wrote: post #33

What really pisses me off about this is that you had to register just to be able to download the files. So they unnecessarily had a lot of people's username/passwords for absolutely no good reason.

http://www.bugmenot.com

I hate sites that require logins. Though apparently this one had a way around it, lots don't, and many of them are already in bugmenot. If not, add a mailinator-based account for others :)

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

#63

Post by nupark »

tptacek wrote: post #59
nupark wrote: post #54

Earlier quoted context omitted.

A "vast number of issues"? Huh? Citation needed. The last time I researched this, I started here: http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3... ... would up and sources like this: http://lists.rubyonrails.org/pipermail/rails/2004-December/0... ... and spent a good hour reading the Rails source code. My take away was that, historically, a lack of care coupled with a lack of use of the parameterized APIs…

People that don't know Rails are going to think that you're making pointed critiques of the framework, when in fact you appear to be repeatedly citing examples of people going through extra effort to use the interfaces Rails provides for directly using SQL instead of ActiveRecord's finders.

I'm not offering a "pointed critique of Rails" ([edit] although your framing it as such seems to encourage downvotes into the negatives). I'm demonstrating how the use of non-parameterized queries source of error that has repeatedly resulted in SQL injection issues in ActiveRecord. I have provided three different examples:

- In the first, the API design itself made it non-obvious/easy to directly concatenate strings while -- at a glance -- appearing to be correct.

- In the second, the API's implementation resulted in SQL injection because :limit and :offset arguments were not correctly escaped.

- In the third, the API's documentation and recommended usage (in 2004) encouraged users to use constructs that appeared to provide defense against SQL injection, but in reality, did not.

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

#64

Post by albertzeyer »

tptacek wrote: post #57
albertzeyer wrote: post #52

Earlier quoted context omitted.

What do you mean? 1. It would be much cheaper and faster. Right now, you are: constructing a string first, doing some escaping, then sending this more bloated pure-text query to the server, then parse the SQL language, unescape, convert back into some machine representation. I.e. a) Most of this extra handling (escaping, string-conversions, parsing) would go away. b) Less data need to be send around. 2. It would actu…

You've made "SQL injection" impossible by inventing "albertzeyerql", which will inevitably be vulnerable to "AZQL injection". Many of the NoSQL's have similar problems; expect to hear more about them in Blackhat presentations yet to come. It's not pointless to discuss how query languages can be made simpler to parse and thus less susceptible to injection, but the technique isn't foolproof and is (obviously) expensive…

I am not really talking about a language at all (at least not on a byte-alphabet).

Maybe we misunderstood a bit. For example, take a look at the [new Redis 2.0 protocol](http://redis.io/topics/protocol). In this protocol, injections are simply impossible. This may not be the best example because you don't really have more complicated queries but you could just do the same for tree-like structures.

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

#65

Post by awj »

tptacek wrote: post #60
awj wrote: post #51

Earlier quoted context omitted.

> It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue. Sure, but it is unreasonable to assert that SQLI defense is not also a database issue. Using the provided apis in a way that prevents SQLI is a framework concern. Providing apis that make that possible without re-implementing basic things like escaping is a database concern, otherwise you're just asking people to re-sol…

SQL defense isn't a database issue. The SQL Injection vulnerability is, "user coerces application into submitting an unexpected and unauthorized query". Blaming the database for that is like blaming the filesystem for pathname injection vulnerabilities. It could, after all, send a Unix signal to a calling process when a filename contained "..", and demand that the process re-assert it's desire to really reference a d…

I think we definitely are spiraling. My argument is about how the stance MySQL took on parameterized queries has affected the product's community. I don't disagree with you on the technical issues. Well, except that providing useful tools to handle SQL defense correctly is a database issue. And pathnames are a read herring, as they are not a transport for data manipulation commands.

I guess part of it is that I'm just done watching various problems with MySQL (transaction support, parameterized queries, subqueries, bizarro query optimization) be given a pass as "not quite MySQL's problem". Maybe I'm just taking that out on this thread.

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

#66

Post by viraptor »

mattmanser wrote: post #33

What really pisses me off about this is that you had to register just to be able to download the files. So they unnecessarily had a lot of people's username/passwords for absolutely no good reason.

Wait, you actually use a real email / password there? I'd like to introduce you to http://bugmenot.com/view/mysql.com and http://sogetthis.com/

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

#67

Post by d2 »

Oracle's security team bear full responsibility for this breach. MySQL's founder Monty Widenius left Sun in 2005. Sun declined, Oracle bought them as a strategic buy and the portal has been neglected to the point of being compromised.

One wonders what internal neglect MySQL is suffering behind the corporate veil.

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

#68

Post by tptacek »

albertzeyer wrote: post #64
tptacek wrote: post #57

Earlier quoted context omitted.

You've made "SQL injection" impossible by inventing "albertzeyerql", which will inevitably be vulnerable to "AZQL injection". Many of the NoSQL's have similar problems; expect to hear more about them in Blackhat presentations yet to come. It's not pointless to discuss how query languages can be made simpler to parse and thus less susceptible to injection, but the technique isn't foolproof and is (obviously) expensive…

I am not really talking about a language at all (at least not on a byte-alphabet). Maybe we misunderstood a bit. For example, take a look at the [new Redis 2.0 protocol]( http://redis.io/topics/protocol ). In this protocol, injections are simply impossible. This may not be the best example because you don't really have more complicated queries but you could just do the same for tree-like structures.

I think you're wrong, both in your general point and about the possibility about Redis query injection; unfortunately, you're wrong in ways I'm not at liberty to correct. I can only ask that you take my word for it that you need to be as mindful with the code that constructs Redis keys as you do with code that concatenates SQL queries. And, as with SQL, much (perhaps most) production-quality code isn't susceptible to attack; but the lines that are tend to blindside you.

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

#70

Post by tptacek »

jschrf wrote: post #50
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…

"In fact they're not injection protection mechanisms at all" What?! Parameterized queries (in any competent implementation) ARE, in fact, injection protection mechanisms. Escaping != Parameterization. Ruby on Rails is a poor example to use here - it's a trendy web language that (judging by your comment) does not use proper database practices. Properly implemented parameterized queries offer protection against SQL inj…

If parameterized queries guaranteed a total separation between user input and query structure, you'd be right. But they don't. They guarantee a separation between some user inputs and query structure.
Post reply on HN