|
Session poisoning
Web Design & Development Guide
Session poisoning
Home
Up
Session poisoning (also referred to as "Session data pollution"
and "Session modification") is to exploit insufficient input validation
in server applications which copies 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 have 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 have been demonstrated in scenarios where attacker is able
to introduce malicious scripts into the server environment, which is possible if
attacker and victim shares a web hotel.
Origins
Alla Bezroutchko inquired if "Session data pollution vulnerabilities in web
applications" was a new problem in January 2006.
This was however an old vulnerability previously noted by other;
Googling for this issue does find hits from
It is possible to dig up much older references, but most old issues are
ungoogleable because no generally accepted term for this issues existed, nor
was it taught/discussed in popular web programming FAQ's such as the
PHPSEC.ORG PHP Security Guide.
Attack examples
Trivial attack scenario
In
Experts Exchange: UserID Session variable data changing?!, it was discussed
that
Session("Login") = Request("login")
Session("Username") = Request("Username")
was subject to trivial attacks such as
vulnerable.asp?login=YES&Username=Mary
Typical examples of such attacks could be if
- User submits username / password to
logon.asp
- If password for
Mary checks outs, logon.asp
forwards to vulnerable.asp?login=YES&Username=Mary
I.e. the problem is that vulnerble.asp is only designed to cope
with when accesses the page in a non-malicious way. Anyone who realizes how the
script is designed, is able to craft a HTTP request which sets the logon user
arbitrarily.
Exploiting ambiguous or dual use of same session
variable
Alla Bezroutchko discusses a scenario where $_SESSION['login']
is used for two different purposes.
- In the login scripts, the session variable stores "This user is logged
on".
- In the password reset scripts, the session variable stores "this user
wants his password reset".
A race condition was demonstrated, in which the reset scripts could be
exploited to change the logged on user arbitrarily.
Exploiting scripts allowing writes to arbitrary
session variables
/someone discusses examples observed in development forums, which allows
writing to arbitrary session variables.
The first example is
$var = $_GET["something"];
$_SESSION["$var"] = $var2;
(in which $_GET["something"] probably is from a selection box or similar).
Attack becomes
vulnerable.php?something=SESSION_VAR_TO_POISON
Session poisoning attacks enabled by php.ini:
register_globals = on
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.
Second example by
/someone is
if ($condition1) {
$var = 'SOMETHING';
};
if ($condition2) {
$var = 'OTHER';
};
$_SESSION["$var"] = $var2;
which is vulnerable if:
- It is possible for attacker to cause both conditions to be false.
- php.ini is misconfigured (register_globals = on), which allows $var
default value to be controlled by GPC (GET, POST, or COOKIE) input.
Attack becomes
vulnerable.php?var=SESSION_VAR_TO_POISON
Exploit utilizing a shared PHP server (e.g. web hotel)
unknow of uw-team.org discusses a scenario where attacker and victim shares
the same PHP server.
Attack is fairly easy:
- The attacker first visits the victim's page, and e.g. log on.
- Attacker then uploads a PHP script to his account, and have it display
context of $_SESSION (set by victim script).
- Attacker determine which variable which needs to be changed, uploads a
script which sets this variable, execute it.
- Attacker visit victim pages and see if exploit the effect anticipated.
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.
See also
Home
Up
Browser exploit
Cross-site cooking
Cross-site request forgery
Cross-site scripting
Cross-zone scripting
Directory traversal
Evil twin (wireless networks)
HTTP response splitting
IDN homograph attack
Referer spoofing
Session fixation
Session poisoning
Website spoofing
|