Comment

Comment by developer2

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.

parent developer2 7 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton