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

21–30 of 117 posts

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

#21

Post by xd »

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.

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

#22

Post by fmavituna »

bjg wrote: post #17
fmavituna wrote: post #9

Same guys hit Sun.com via SQL Injection as well - http://tinkode27.baywords.com/sun-com-sun-mycrosystems-vulne... Shameless self plug: Netsparker ( My startup: http://www.netsparker.com/ ) could have identified both of these vulnerabilities.

That product looks awfully similar to Metasploit ( http://www.metasploit.com/ ) , no? How is it different? I watched the demo video and couldn't really tell.

Metasploit mostly focuses on Infrastructure and exploiting known vulnerabilities.

Netsparker is solely focused on web application security (detection & exploitation). For example Netsparker can crawl AJAX/Javascript apps, support form authentication etc. Metasploit on the other hand possibly will never do that kind of stuff.

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

#23

Post by albertzeyer »

xd wrote: post #8
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 (…

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 some binary representation to the server (mostly like Prepared Statements in MySQL). Whereby I think that this step is obsolete and would in any way produce further problems.

Btw., this is not exactly like NoSQL what I am talking about here.

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

#25

Post by awj »

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'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 situation while giving MySQL a pass.

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

#26

Post by xd »

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…

How can you say everyone should be fine using a simple construct like that, have you ever had to write a complex query on a non-trivial database?

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

#28

Post by Natsu »

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.

PHP has been known to provide convenient footguns in the past (e.g. register_globals, mercifully depreciated), so it's not surprising that security-minded people give it a hard time.

Think of it as the difference between the language keeping loaded footguns under its pillow with the safety off and keeping unloaded footguns in a locked gun safe. One is a lot less likely to get used than the other, even if either one will shoot your foot just as well.

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

#29

Post by xd »

Natsu wrote: post #28
xd wrote: post #21

Earlier quoted context omitted.

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

PHP has been known to provide convenient footguns in the past (e.g. register_globals, mercifully depreciated), so it's not surprising that security-minded people give it a hard time. Think of it as the difference between the language keeping loaded footguns under its pillow with the safety off and keeping unloaded footguns in a locked gun safe. One is a lot less likely to get used than the other, even if either one w…

Rehashing old design floors is not an excuse to blame PHP for programmer error.

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

#30

Post by albertzeyer »

xd wrote: post #26
albertzeyer wrote: post #23

Earlier quoted context omitted.

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…

How can you say everyone should be fine using a simple construct like that, have you ever had to write a complex query on a non-trivial database?

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