This often comes up. If a language or platform has a misfeature which makes it hard to write secure code, it is hard for experts in that language to see why it's a problem. In principle, there is workaround XYZ which you should clearly use if you care about that stuff, but otherwise it is working as designed. The argument that *in practice* lots of programs end up with security holes does not carry the weight it should.
It's similar to user testing: you may test your application thoroughly but when you give it to real users they do all sorts of things you didn't expect and will inevitably find bugs. Constructs which lure unsuspecting programmers into opening security holes (even though those programmers are not totally clueless or careless) should be treated as a security bug just as severe as the hole itself.
Posted Mar 5, 2012 13:57 UTC (Mon) by clugstj (subscriber, #4020)
[Link]
But in this case, it appears that he got pissed off at the "experts in that language" (rails) and took it out on "real users" (github). Not at all a nice thing to do.
Github compromised, or not?!
Posted Mar 5, 2012 14:33 UTC (Mon) by sorpigal (subscriber, #36106)
[Link]
Seems more like he took it out on the expert's issue tracker, which just happens to be run by someone else. A kind of an in-your-face way to make your point, but very effective.
Github compromised, or not?!
Posted Mar 8, 2012 22:06 UTC (Thu) by bronson (subscriber, #4806)
[Link]
And very necessary because Rails doesn't actually host anything itself. If you're going to demonstrate a trivial attack on Rails, you're going to have to select one of the many sites that use rails.
In this case, just demonstrating the attack is pointless because the docs already say, "don't do that." Homakov needed conclusive evidence that even good Rails programmers miss the docs sometimes.
Github compromised, or not?!
Posted Mar 5, 2012 14:26 UTC (Mon) by XTF (guest, #83255)
[Link]
> If a language or platform has a misfeature which makes it hard to write secure code, it is hard for experts in that language to see why it's a problem.
Exactly. How many SQL injection vulnerabilities are the result of PHP's mysql_query() design for example?
Github compromised, or not?!
Posted Mar 5, 2012 17:27 UTC (Mon) by ajross (subscriber, #4563)
[Link]
Actually, if you want to pick on php, the register_globals() misfeature (now fixed) is a closer fit. Rails, (apparently, under the default idiom "everyone uses"), allowed an attacker to override fields in the model object via unexpected CGI paramters. PHP using register_globals() gadget suck the CGI parameters in as global variables.
Basically the same stupid mistake. It's a collision between convenience (representing query parameters as variables automatically without the need to explicitly parse/validate/declare/etc...) and safety (forgetting that the resulting variables are potentially from untrusted sources). Rails leans heavily on the DRY principle, and would be expected to be particularly susceptible to this kind of goof.
Github compromised, or not?!
Posted Mar 6, 2012 8:22 UTC (Tue) by Los__D (guest, #15263)
[Link]
Wouldn't that be MySQL's mysql_query?
Github compromised, or not?!
Posted Mar 9, 2012 12:57 UTC (Fri) by knobunc (subscriber, #4678)
[Link]
Nope. mysql_query() is PHP's dangerous by default interface to the mysql DB. There are better ways to do it, but that was one of the earliest, and is documented all over the place.