Rails' Insecure Defaults

&#62; The fix: Rails 4 changed the default session store to be encrypted. Users can no longer decode the contents of the session without the decryption key, which is not available on the client side.<p>Seriously? So they've added a whole more complexity to the session-layer just because people abused it to store "secret" data? Newsflash: If you don't want the client to be able to read the data, DON'T SEND IT TO THE CLIENT AT ALL. Way more secure than encrypting it.

I'm very glad to hear about the regex exceptions. Ruby's weird behavior for ^ and $ is something I never would have guessed, since Perl, Java, and Python treat it differently. I bet there are a lot Rails apps out there with this insecurity.<p>I'd also like to see secret tokens extracted from source code to something like an ENV var. I know a lot of Rails dev shops have a "Rails template" They use to start new projects, so beyond the Github issues the article mentions, I wonder how many projects have to same copy/pasted secret token.<p>I also appreciate the warnings about off-site redirects and hrefs with untrusted input.

I don't agree on WEBricks verbose headers being a problem. It should not be used in production anyway and during development getting lots information easily is obviously very useful.

You can't fool proof a framework into making it impossible for a developer to <i>make</i> it insecure.

Insecure defaults s^cks.<p>On a semi-related sidenote all the recent Rails exploits prompted a heated discussion on the Clojure devs (the developers developing Clojure itself) group / mailing-list about an insecure Clojure default value.<p>Some devs realized that using exploits similar to the Ruby ones in YAML deserialization rogue code could be run on the Clojure webapp server if certain functions were used... And the argument to force the benevolent dictator to act was precisely that the Ruby issue basically turned into a gigantic endless mess of compromised systems and patches.<p>In Lisps it's all too easy (which is good) to read data and to eval it by mistake (which is bad): Clojure by default ships with read-eval set to true which is maddening. These aren't safe defaults and several webapps are vulnerable. Sadly as I understand it that default behavior is so relied on upon by everything in the Clojure ecosystem that Rich Hickey decided not to change it to false.<p>Instead Clojure ships with insecure defaults and big fat warnings in the documentation saying: <i>"You should not use this function, use the EDN functions instead"</i>. And it is recommended that everyone sets <i>read-eval</i> to <i>false</i>. Still as far as I understand it even when read-eval is set to <i>false</i> some functions do still have side effect (in Java land) and could potentially be used maliciously.<p>That's the big problem: I don't understand it all because it's super technical (Rich basically told people on the mailing list they weren't qualified enough to discuss about what the defaults should be). All I know is that I'm supposed to set read-eval to false and also not to use read-string etc. but instead use the EDN functions.<p>And then I guess "cross fingers" because "we promise you this way you'll be secure". I only half-buy it but whatever, I do still love Clojure as of now.<p>I think it's really sad that security seems to <i>always</i> be an afterthought. The very rare projects I know of which were conceived with security as the main reason are OpenBSD and it's OpenSSH implementation (which is also into Linux etc.) and esL4 (a 7000 lines microkernel from which hundreds (!) of bugs have been found and eliminated using a theorem proover).<p>I can't help but dream of the day were devs are going to take security seriously and ship with safe defaults.<p>Probably not for this decade but the situation is getting so messy that I'm certain something shall be done at some point.<p>And while some here are busy "getting real things done in PHP and Ruby" (which is great as long as you're not diminishing others), I want to thanks all the devs working on torny security issues and thinking about security from the start. Like all these Ph.Ds working on theorem provers etc.

The article is good, to the point, highlighting tangible points well. However, I do worry it is wasted a little. The bulk of Ruby on Fails developers are too enamoured with Magic and the promise of the five-minute-blog to really think about security or software engineering.