34 ms·
I'm going to stick my neck out as someone who has refused to even consider Rails over a span of many years, for one simple reason: it permits session fixation.
by developer2 7y ago
I'm going to stick my neck out as someone who has refused to even consider Rails over a span of many years, for one simple reason: it permits session fixation. If a client's cookie says "I am session token 'abc123'", it will create that session id out of thin air. As in, it will create that session id without it having had to be generated previously. Your memcached/redis does not have an entry for session 'abc123', but Rails will happily create it.
The developers who allowed this situation to occur should not be permitted to be employed in our industry. Yes, it's that bad and I am that serious. You can, not kidding, set your cookie's value to ANY VALUE YOU WANT, and the codebase is entirely willing to unconditionally create that session with whatever value the attacker chooses.
Hint: if a client sends session id "abc123", then you should check for the existence of that session id. If the key is not set, you either a) show an error page, or b) create a completely new session id, ignoring the client's requested session id. It is NEVER, EVER, EVER... I am saying __NEVER__, __EVER__ acceptable to create a session id based on client-provided data. And yet, this is what Rails does out of the box.
Edit: Downvote me more, I don't care. The fact is that Rails' developers are amateurs. Rails is insecure out of the box. That is a fact.
- excid3 7y agoThe countermeasures to session fixation are covered in the official Rails guides: https://guides.rubyonrails.org/security.html#session-fixation-countermeasures https://guides.rubyonrails.org/security.html#session-fixatio...
- developer2 7y agoWhy is that an opt-in option? No codebase should ever be willing to create a session id (any db/cache id/key) based on request details. The fact you have to opt in to a very basic security measure is, once again, a joke. Let's be clear: by default, Rails is willing to assign a client any session id based on its own request?!?! Based on the other reply to my comment... no I'm not OK. I am not OK with Rails' pathetic attempts at the most basic level of security. Rails' developers are fucking amateurs. I'm sorry, but that's pure fact. Rails' developers don't know the first thing about the HTTP protocol. NOBODY EVER CREATES A DB/CACHE KEY BASED ON THE VALUE OF A CLIENT-PROVIDED COOKIE (or unvalidated GET/POST). Anyone who argues against this should be permanently banned from IT/Technology. Just... fuck off... you have no clue.
- deleted 7y ago[deleted]
- codeisawesome 7y agoYou may have a valid point but your rant-y syntax is what’s earning you the downvotes :/
- i_call_solo 7y agoyou ok?
- slig 7y agoI'm not a rails user, but if what you're saying was that bad it would've been exploited and fixed already.
- deleted 7y ago[deleted]
- zawerf 7y agoCan you describe how you can exploit this? It's good for defense in depth, but you have to pwned the user in another way to set the cookie in the first place right? If you're using httpOnly cookies you should be fine? (Not an expert and genuinely want to know because it seems like the node.js ecosystem doesn't consider it a problem worth fixing either: https://github.com/jaredhanson/passport/issues/192 https://github.com/jaredhanson/passport/issues/192 )
- chipotle_coyote 7y agoCookies in Rails are encrypted and signed, and as far as I am aware, simply setting your session hash cookie to a bunch of random gibberish is not, in fact, going to just create a new session. (Also, "creating a new random session" is not what a session fixation attack is, but let's leave that aside for now.) Given this encryption, how do you propose to execute this attack? I don't usually like to be the "[citation needed]" guy, but: citation needed.