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

81–90 of 117 posts

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

#81

Post by morgo »

d2 wrote: post #67

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.

Do you really think Monty had anything to do with coding the website anyway?

The guys that write the actual database have nothing to with the web team. They didn't in MySQL days, they don't now.

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

#82

Post by albertzeyer »

tptacek wrote: post #68
albertzeyer wrote: post #64

Earlier quoted context omitted.

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…

Now that made me curious...

Can you say when/where I could read about that?

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

#84

Post by albertzeyer »

__david__ wrote: post #56
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…

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.

Yes, this looks much like what I want from the outside/usage.

But the implementation of it is actually again the error-prone and slow way to generate a SQL-statement from that, then send that to MySQL and MySQL parses it back to get the original structure.

I actually want to complete avoid that step to generate an SQL statement.

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

#85

Post by zwp »

tptacek wrote: post #76
zwp wrote: post #74

Earlier quoted context omitted.

> you can solve it by blindly calling #to_i on your inputs "You can solve it by blindly calling #h on your outputs" Ouch. We know that scheme doesn't work too well: it's why we had #h and we now have #html_safe...

Not comparable. h() was a one-sized-fits-all problem to quoting things that could occur anywhere in an HTML DOM. #to_i assures that a bit of syntax that can only ever accept integers is in fact given a real integer. In case we're misunderstanding each other, I'm also saying that the framework should be doing that, not the caller (as was the case with h()).

Thanks, yes misunderstanding: agree should be a framework protection not something developer should be sprinkling over code.

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

#87

Post by [deleted] »

tptacek wrote: post #42
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.

You're right: that's an annoying plug. Please don't do that.

[deleted]

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

#88

Post by stephth »

tptacek wrote: post #68
albertzeyer wrote: post #64

Earlier quoted context omitted.

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…

tptacek, are you claiming you are aware of critical vulnerabilities in Redis?

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

#89

Post by statictype »

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 not every input to every query can be bound as a variable" Can you give me an example?

var sql = "select * from User where UserType=@ut order by ModificationDate " + sort_order;

In this case, if sort_order directly comes from a 'asc'/'desc' radio button then you have an injection attack.

The correct way to do it would be:

var sql = "select * from User where UserType=@ut order by ModificationDate " + (sort_order=="asc"?"asc":"desc");

The point was that there are some parts of sql that can't be parameterized like sort order or limits on the resultant recordset. Although, ideally support for those things should be coming from your database vendor (if it isn't already there).

For example, SqlServer supports using variables in top expressions: select top(@max) * from ....

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

#90

Post by jschrf »

tptacek wrote: post #70
jschrf wrote: post #50

Earlier quoted context omitted.

"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.

Can you elaborate on this?

Given a properly parameterized query, where none of the parameters are ever evaluated, how do any user inputs remain unseperated from query structure?

Post reply on HN