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

51–60 of 117 posts

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

#51

Post by awj »

tptacek wrote: post #35
nupark wrote: post #31

Earlier quoted context omitted.

> 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 LI…

> 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-solve the same problems so they each get a chance to screw it up.

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

#52

Post by albertzeyer »

tptacek wrote: post #41
albertzeyer wrote: post #30

Earlier quoted context omitted.

You will be able in a straight-forward way to extend this to allow any possible query.

Thus arriving, via the most circuitous and expensive plausible path, right back at the problem we have today.

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 actually make SQL injections impossible and thus solve all these problems.

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

#53

Post by xd »

tptacek wrote: post #38
xd wrote: post #18

Earlier quoted context omitted.

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.

"Prepared statements do not afford you a "clean conscience"" erm, that was the point I was trying to make.

"because not every input to every query can be bound as a variable" Can you give me an example?

"Some operations do require dynamic query construction." what does that have to do with prepared queries?

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

#54

Post by nupark »

tptacek wrote: post #49
nupark wrote: post #44

Earlier quoted context omitted.

It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue. The database is the normative reference on what is and is not a special cased character and how escaping should be implemented. I don't think it's reasonable to assert that escaping is a concern that should be adopted by every framework that might ever talk to a database. The examples you've provided of Rails SQLI issues…

A "vast number of issues"? Huh? Citation needed. I don't know how to respond to any of these points. The discussion at hand is, "who's job is it to defend against SQLI, the database, the framework, or the application?". Of those three components, the database is least well equipped to defend against SQLI. SQLI is "avenue for attacker to submit queries to a database contrary to the intentions of the application". The…

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 left the door open to repeated failures in the implementation to protect against SQL injection.

Things have improved in Rails, but as a historical example of the pitfalls of ignoring/eschewing parameterized query APIs, I believe it to be quite valid.

The discussion at hand is, "who's job is it to defend against SQLI, the database, the framework, or the application?". Of those three components, the database is least well equipped to defend against SQLI. SQLI is "avenue for attacker to submit queries to a database contrary to the intentions of the application". The database's simple job is to accept and execute queries.

No, you're reframing the discussion. The original poster commented on MySQL's longtime begrudging support for parameterized queries (or lack thereof) as one of the major causes of the prevalence of SQL injection issues.

It seems clear to me that the database -- as the central implementation responsible for parsing queries -- is the best equipped to provide safe, correct string interpolation of those queries.

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

#55

Post by riffraff »

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.

I redownloaded mysql yesterday and while it _seems_ you have to register you doin't actually have too

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

#56

Post by __david__ »

albertzeyer wrote: post #23
xd wrote: post #8

Earlier quoted context omitted.

SQL is a human readable language .. what do you mean by "real binary protocol" ?

The language itself doesn't matter at all. Everybody would be fine to use some construct like: Select(args=["name", "id"], from="students") And maybe "name", "id" and "students" also could be replaced my some reference pointers. But in case someone really wants to keep the language, you could still do the parsing inside of the lib and thus for example disallow multiple commands in one statement and then only send som…

That looks like perl's DBIx::Class library. http://search.cpan.org/dist/DBIx-Class-0.08127/lib/DBIx/Clas... has a lot of example queries.

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

#57

Post by tptacek »

albertzeyer wrote: post #52
tptacek wrote: post #41

Earlier quoted context omitted.

Thus arriving, via the most circuitous and expensive plausible path, right back at the problem we have today.

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; meanwhile, the proper defense against SQLI (being mindful about query inputs, and using the framework to abstract and normalize dynamic queries) is available today and works well.

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

#58

Post by tptacek »

xd wrote: post #53
tptacek wrote: post #38

Earlier quoted context omitted.

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.

" Prepared statements do not afford you a "clean conscience" " erm, that was the point I was trying to make. " because not every input to every query can be bound as a variable " Can you give me an example? " Some operations do require dynamic query construction. " what does that have to do with prepared queries?

Because when you try to use a prepared statement to populate a paginated table, you still force the database to construct a dynamic query based in part on user inputs when you pass the OFFSET and LIMIT to it.

Recommended exercise: implement the MySQL wire protocol. It took me a couple hours a few years ago. It's not hard. Do it, come back, and then see if you still think the same things about SQLI defenses.

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

#59

Post by tptacek »

nupark wrote: post #54
tptacek wrote: post #49

Earlier quoted context omitted.

A "vast number of issues"? Huh? Citation needed. I don't know how to respond to any of these points. The discussion at hand is, "who's job is it to defend against SQLI, the database, the framework, or the application?". Of those three components, the database is least well equipped to defend against SQLI. SQLI is "avenue for attacker to submit queries to a database contrary to the intentions of the application". The…

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.

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

#60

Post by tptacek »

awj wrote: post #51
tptacek wrote: post #35

Earlier quoted context omitted.

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 LI…

> 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 different directory.

We may be spiraling here. Parameterized queries are a good thing. I'm glad MySQL has them. I'm not, however, going to wag a finger at MySQL every time someone finds an SQLI vulnerability in an app that uses MySQL, just because 6-7 years ago they didn't have parameterized queries. For one thing, it's not a useful comment (do you want them to implement parameterized queries... again?); for another, it's not particularly valid architectural point; and finally, it's really boring.

Post reply on HN