Recently I've been made aware of people inside US Government organizations using my Ruby on Rails Security presentation as an excuse to limit Ruby on Rails adoption and projects inside those organizations.
They mandate that applications in Rails should be redone in Java because of the issues I covered.
It is not clear to me how anybody who saw/read this presentation would come to the conclusion that Rails is insecure. Every application is vulnerable. Some more and some less. Yes, this means that also Java applications are attackable.
It is my honest and strong belief that Ruby on Rails applications are not less secure than any other web application. In contrast, the Ruby on Rails framework provides several advanced security mechanisms that make it very easy to write secure applications. Further, Ruby on Rails enables very sane security options by default. Some of those defaults include auto-escaping, prevent Cross-Site Request Forgery, or protected from SQL-injection. I would even go as far as to state that the typical Rails application is more secure than the typical web application for those reasons.
The security of an application stands and falls with the knowledge and abilities of the people implementing and running it. Rails makes it very easy to write secure applications.
The conclusion I came to in my presentation still holds:
Ruby is by no means a "web app security silver bullet" but adding security is easy and not a pain like in many other frameworks
I hope this will change the opinion of some people and remove my presentation as their argument.
Well that thing with the cookie session storage is not good. It’s more or less common wisdom to only store the key to session into the cookies, and keep the actual session data elsewhere. I was honestly baffled to read those couple slides, considering posting them to thedailywtf.com ….
The rest are as you said: Similar to what the others are doing as well, and manageable reasonably.
Thanks for getting this out there. The US Government is masterful at wasting tax dollars, and this is a really good example of how they’ve elevated it to an art form. Rewriting applications from ruby to java? BAH!
The default session store thing is true in that way that an attacker can read what is in his session. He cannot modify or create content. If you do not like this (and I do), changing it is very easy. It is just one line of configuration.
That said, most apps can live fine with it as they just have the user_id in the session. If you have valuable content in it you are prone to session replay attacks.
“I was honestly baffled to read those couple slides, considering posting them to thedailywtf.com ….”
The real wtf is this statement. Cookie session storage isn’t designed to be secure. It’s designed to be convenient, lightweight and very developer friendly. If you, as a developer, are putting together an application that requires actual security and you’re using cookie session storage, well, unlike mehmoomoo, you should know better.
The Java people that interpret this as meaning “Rails is insecure” most likely then go back to building SQL by concatenating query parameters without escaping. Because Java is always secure, right?
And session editing by brute-forcing HMAC-SHA1, while possible in theory, is likely to take ridiculous amounts of time. For example, the much faster HMAC-MD5 can be scanned at about 4 million hashes/second on a dual 3.2GHz Xeon box (from the MDCrack homepage). So to force a 30 character hex key like Rails generates by default, a quick calculation (1630 / 4000000) yields roughly 1030 seconds, or 10^22 YEARS. Sure, with two billion Xeons in a cluster, you might finish sometime before the heat death of the universe. But I’d hardly class that as “insecure”.
Garren, you do things according to widely known best practices not because they are always correct but because of consistency and its risk reducing behaviour. Also, 4k storage limitation is bad for many applications.
There is by the way no need for argumentum ad hominem.