Session Protection

The Session Protection module protects user sessions against hijacking attacks and offers a better method to protect from session fixation than the one provided by Drupal itself.

The method implemented by this module is based on session fingerprinting. A unique string is computed and attached to session data. The same exact string is computed for every page request, so it should be based on data that isn't prone to change (or that it doesn't change really often). The first time a user generates a request, the fingerprint is stored in session data. Subsequent requests will check the computed fingerprint against the one stored in session data. If it doesn't match, the request will be forced to use a new session id, logged out and redirected to the homepage. While that happens, the victim (the user who originated the first session) is not affected. ie. its session id along its session data remains untouched.

At a bare minimum, the fingerprint should take into account the user ID. Note that changes in the fingerprint will force a regeneration of the session id, hence, this method protects from session fixation attacks.

The user agent string is also used to compute the fingerprint. While this information could be easily spoofed, it still helps in that

• this information doesn't change (or shouldn't) between page requests and

• an attacker should not only know the session id, but also the user agent string of the victim.

Optionally, the user ip (or part of it) may also be taken into account to compute the fingerprint. This is a method of session hijacking prevention that comes at the price that some legitimate users may be logged out when their IP (or the part of it that is taken into account here) changes. This may affect users who browse the site behind certain proxy farms, such as AOL, etc. This isn't reason enough to remove this kind of checking because:

• proxy farm vendors are aware of the problem, of course, hence they provide methods to ensure a common IP range for users during the lifetime of their sessions. It seems, therefore, reasonable to provide with this type of protection.

• admins deserve the right to choose the level of protection their sites may need. Some may not care about users behind proxy farms, also some may operate behind intranets, etc. ie. it depends on their target audience.