[jrabone]

Who'd have thought it? Hugely dynamic language turns out to be difficult to audit or analyse for security issues.

It was never about Java(C, C++) vs. Ruby despite what fanboys on either side made out. It was about conservative vs. devil-may-care. All that "convenience" and "it's so clean" came at the price of a whole load of code executed behind the scenes. You didn't write it, and the Gods of TDD preached that you don't need to test it because that's Someone Else's Problem. Auditing it is nearly impossible not least because it's a moving target, so you either get stuck in a backwater of obsolete versions that once got audited and approved or you live on the bleeding edge constantly (and DevOps hate you forever).

FWIW we (large satnav company) prototyped the last major service in Rails (actually a one-man hack proof of concept) then implemented it in production in Scala (and that was a bridge too far for a lot of people) because no-one wanted to run Rails in production.

[phillmv]

This is a straw man.

These kinds of issues are open to all software.

I'm happy you work in the kind of place that audits all of its software, though. I'm sure you've all read through all of Hibernate, Spring and not to mention all the .NET framework code.

[revelation]

That is a straw man. Nobody claims there are not issues in other software.

The claim here is that people in dynamic languages tend to misuse that and write all sorts of magic that are pure gold for 10-line snippets but open up a vast attack surface, like building completely arbitrary objects from string input.

[papsosouid]

>These kinds of issues are open to all software

Really? Could you show me how I could possibly create such a hole in a language like ocaml or haskell?

[chimeracoder]

> Could you show me how I could possibly create such a hole in a language like ocaml or haskell?

First you'd have to write the equivalent of Rails in Haskell (I'm not talking about an MVC framework, but something as large, complex, and featureful.)

[papsosouid]

No, I am asking how you could actually create this vulnerability in haskell at all. No framework required, just actively, intentionally trying to create this hole.

[bri3d]

Here's a very, very similar exploit from last year... in a popular enterprise Java stack:

http://websec.wordpress.com/2012/01/04/multiple-vulnerabilit...

[pacala]

> The value of a parameter id was reflected to the HTTP response

The link you posted illustrates that it is unfortunate that Java supports reflection, and even more unfortunate that various "enterprise" software stacks abuse reflection in ever more creative ways. Stay away of Java reflection and/or use C/C++, and you'll avoid this kind of vulnerabilities.

[senorprogrammer]

This isn't about languages; what the language gives the language can take away. This is about diligence, responsiveness, and transparency.

Rails will always have zero-day security issues; I'd hazard that all web apps of any notable size will. What matters most to me is how the core team and community respond on those three criteria above.

Lately the Rails team has been performing exceptionally.

[mtrimpe]

Wait, which one of us are you?

[jrabone]

One of the troublemakers on a small island :-)

You've escaped anyway.