4

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?

Community
  • 1
  • 1
mth
  • 490
  • 2
  • 12

1 Answers1

5

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.

diedthreetimes
  • 4,086
  • 26
  • 38
  • "MD5 is uncompromised"? Considering how easy it is to engineer collisions, and the prevalence of huge rainbow tables, I'd say that's a minority opinion. – Leopd May 10 '12 at 16:27
  • @Leo Mmmm, I partially agree with you. I would not call MD5 uncompromised, and SHA-1 should really be used here. That being said, the point being made is accurate. Rainbow tables do not help crack random passwords (rainbow tables exist for SHA as well), and collision calculating requires some control of input being hashed. In this context I find it extremely unlikely that the a collision could be generated. A larger problem IMO, is the source of randomness used, as it doesn't sound cryptographically secure (i.e. if we know enough about the machine we can guess the random number and process id) – diedthreetimes May 10 '12 at 20:25
  • That being said, anyone generating a colliding session_id seems extremely rare. – diedthreetimes May 10 '12 at 20:26
  • 2
    I don't see evidence that MD5's weaknesses would cause problems with the rails session id system. But I would not say that MD5 is uncompromised if I wanted to be taken seriously. The security comes down to the random number really, as the others are relatively easy to guess. I understand that Ruby's random numbers are pretty good, but not cryptographically secure. – Leopd May 10 '12 at 20:36