Question

I am co-developing a simple web app in Rails 3.0.9 and I have realized that there is a possible session_id tampering possible via malicious request. Mind the fact, that this is my first RoR application, so I could be totally wrong in my conceptions.

Current application functionality requires sessions so I turned to ActiveRecordStore session storage, installed it and started testing in primitive workflows. I noticed that Rails framework creates cookie with the name _session_id and value of some random hash-like string (in DB SESSION table this string corresponds to session_id column).

If that value in the cookie is changed, for example with Firebug, current session id changes to one provided with cookie’s data (inspected with request.session_options[:id]), and the change is propagated to the database table, creating new session record with aforementioned parameters.

While this brings no implications on a variables of the session, the session id have deviated from its usual hash-like appearance to a user tampered one.

Here is the question – how this behavior can be detected or preferably prevented?

Answer 1

To answer your question, it is important to understand the mechanics of how the session-id is generated. (from the docs)

A session id consists of the hash value of a random string. The random string is the current time, a random number between 0 and 1, the process id number of the Ruby interpreter (also basically a random number) and a constant string. Currently it is not feasible to brute-force Rails’ session ids. To date MD5 is uncompromised, but there have been collisions, so it is theoretically possible to create another input text with the same hash value. But this has had no security impact to date.

So the session ID is engineered to be cryptographically “hard” to guess. An attacker could change the session_id but the idea is that they could never guess a valid session.

How can this be prevented?

Based on the above logic, if you lower your session expiration times, there will be considerably fewer “live” session_id’s. Thus making it even harder for an attacker to randomly select a usable id.

How can this behavior be detected?

The easiest way is to log all requests with invalid (not expired) session id’s. If you see a considerable influx of such requests, someone is probably attempting to acquire a session that is not their own.