Session poisoning (also referred to as "session data pollution" and "session modification") is a method to exploit insufficient input validation within a server application. Typically a server application that is vulnerable to this type of exploit will copy user input into session variables.
The underlying vulnerability is a state management problem: shared state, race condition, ambiguity in use or plain unprotected modifications of state values.
Session poisoning has been demonstrated in server environments where different, non-malicious applications (scripts) share the same session states but where usage differ, causing ambiguity and race conditions.
Session poisoning has been demonstrated in scenarios where attacker is able to introduce malicious scripts into the server environment, which is possible if attacker and victim share a web host.
Session poisoning was first discussed as a (potentially new) vulnerability class in the Full disclosure mailing list.[1] Alla Bezroutchko inquired if "Session data pollution vulnerabilities in web applications" was a new problem in January 2006. However, this was an old vulnerability previously noted by others: "this is a classic state management issue" - Yvan Boily;[2] "This is not new" - /someone.[3]
Earlier examples of these vulnerabilities can be found in major security resources/archives such as Bugtraq, e.g.
Session pollution has also been covered in some articles, such as PHP Session Security, Przemek Sobstel, 2007.[6]
An example code vulnerable to this problem is:
Session("Login") = Request("login")
Session("Username") = Request("username")
Which is subject to trivial attacks such as
vulnerable.asp?login=YES&username=Mary
This problem could exist in software where
logon.aspMary checks out, logon.asp forwards to vulnerable.asp?login=YES&username=MaryThe problem is that vulnerable.asp is designed on the assumption that the page is only accessed in a non-malicious way. Anyone who realizes how the script is designed, is able to craft an HTTP request which sets the logon user arbitrarily.
Alla Bezroutchko discusses a scenario where $_SESSION['login'] is used for two different purposes.[7]
A race condition was demonstrated, in which the reset scripts could be exploited to change the logged on user arbitrarily.
Alla Bezroutchko discusses examples observed in development forums, which allows writing to arbitrary session variables.[8]
The first example is
Attack becomes
vulnerable.php?something=SESSION_VAR_TO_POISON
php.ini: register_globals = on is known to enable security vulnerabilities in several applications. PHP server administrators are recommended to disable this feature.
Note: Real-world examples of session poisoning in enabled by register_globals = on was publicly demonstrated in back in July 2001 article Serious security hole in Mambo Site Server version 3.0.X.[9]
Second example by /someone is[10]
Attack becomes
vulnerable.php?var=SESSION_VAR_TO_POISON
'unknown' of uw-team.org discusses a scenario where attacker and victim shares the same PHP server.[11]
Attack is fairly easy:
This attack only requires that victim and attacker share the same PHP server. The attack is not dependent on victim and attacker having the same virtual hostname, as it is trivial for attacker to move the session identifier cookie from one cookie domain to another.