LD SoftwareBespoke Software, Web Design, Security Consultants and Host Services.

Menu

Sentinel
You have been warned!
We have caught 5848 shameful hackers.

NukeSentinel(tm)

Paypal Referral
Sign up for PayPal and start accepting credit card payments instantly.

Link Exchange
Join our free link exchange

Click Here
 
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

Web Design & Development Guide, made by MultiMedia | Websites for sale

This guide is licensed under the GNU Free Documentation License. It uses material from the Wikipedia.

 

Text Ads
There isn't content right now for this block.

Community Login
Welcome,
Anonymous

Nickname
Password
   

People Online:
Visitors: 35
Members: 1
Total: 36

Online Now:
01 : Monty

Like my code
Then please make a donation.

Which help me produce more free code.


Paypal Verified

Information

Powered by PHP-Nuke

Valid CSS!


Valid Robots.txt

Bad Behavior

[Valid RSS]

[Valid RSS]
You can syndicate our News with backend.php And our Forums with rss.php
You can also access our feeds via Feedburner Site News and LD Software Forums
© 2009 ld-software.co.uk All Rights Reserved.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.41 Seconds