PHP and Session Fixation

In December 2002 Acrossecurity released a paper about a new kind of attack onto session managment systems, which they called session fixation.

The basic idea of session fixation attacks is, to force the attacked victim (through any kind of other attack) to use a session ID supplied by the attacker. This eliminates the need of a session ID theft, because the attacker knows the session ID beforehand.

In their paper they divide session managament systems into two segements:
  • permissive: systems (like PHP), that accept all session identifiers and autocreate new sessions for previously unknown identifiers
  • strict: systems, that only allow session identifiers created within the system
Because Acros and after them many other Web Application Security guys consider permissive systems a lot easier to attack PHP is often criticised for its behaviour. Their arguments can be best explained by the following figure of the session fixation process tree, that was taken from the Acros paper. In this figure the (for this discussion) irrelevant part between 2) and 3) was omitted.

In this figure they point out, that for strict systems you need some kind of session maintenance to keep the session alive before it times out. On the other hand they say this is not necessary for permissive systems. But what this figure clearly omits is a detailed analysis of the process after point 3. "Wait for the user to login" is mentioned as step in the process tree. But what does this actually mean for a fixed session?

We assume (like it is done for the process between 1) and 2)) that there is a session timeout of about 30 minutes. This actually means, that after the user has used the session id we have to take over the session within a 30 minutes timeframe. However we very seldom (or better said nearly never) know the exact point in time, when a user will use the session and therefore we have to guess an earliest startpoint and come back f.e. every 25 minutes and check if the user has already used the session.

This actually means that the point "Wait for the user to login" means in reality: perform something very similar to the steps mentioned under 1a) until the user has used the session. Once one has realised that, it is obvious that it doesn't matter if a strict or permissive session managment systems is used, it is always needed to keep the session alive (when there is a timeout at all) and the only additional action, that is required in strict systems, is visiting the site one time more to get the identifier instead of making one up. And this is trivial, even if the whole attack is performed with an XSS vulnerability that overwrites the associated session identifier. (I am mentioning this, because I was recently confronted with the previous example when I spoke about my view. The other side simply forgets, that when you are able to set f.e. a cookie you can usually also read it and therefore you can steal the real identifier and do not need a fixation attack at all.)

And with that said, it becomes clear, that everyone crying out loud that PHP's permissive system is horrible insecure is maybe simply not understanding how real life attacks have to work.

Finally I would like to discuss this article within this thread. Feel free to post any example that could convince me that I am wrong. Until today noone could come up, with such an example.

Stefan Esser

© Hardened PHP Project