Message-ID: <01f001c61ac7$6d198180$7646f480@dom1.jhuapl.edu>
Date: Mon, 16 Jan 2006 13:05:25 -0500
From: "Keenan Smith" <kc_smith@...rk.net>
To: "'Alla Bezroutchko'" <alla@...nit.be>, <bugtraq@...urityfocus.com>,
	<full-disclosure@...ts.grok.org.uk>
Subject: RE: Session data pollution vulnerabilities in web
	applications


Since a session has to be initialized (session_start or
session_register) before it can be used, another approach could be to
initialize a session only after a successful login.  All other values
are stored and accessed in and from _request variables.  That way,
nothing would be stored across requests and apps like "resetpw3.php"
would require all data submitted at once. (i.e. first request is for a
username; second request for the answer to the secret question includes
the username as part of the to-be-submitted form; final submittal
includes all necessary data).

I'm not sure what you describe is a bug as much as it is a poor
programming practice.

Keenan

-----Original Message-----
From: Alla Bezroutchko [mailto:alla@...nit.be] 
Sent: Thursday, January 12, 2006 6:33 AM
To: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
Subject: Session data pollution vulnerabilities in web applications


In web applications I've tested recently I have stumbled upon something
that seems to be new class of bugs. Quick googling did not turn up any
reference to this kind of vulnerabilities, so I thought I should
describe it.

The problem boils down to the application reusing the same session
variable name in different application functions. In one function the
session variable is initialized from the user supplied data, and in
another function the value of the same session variable is used to
perform some sensitive action.

Here is an example. Suppose you have a web application that requires
authentication with login and password. New users can register by
filling in a form (let's say displayed by register1.php). register2.php
takes the form data, saves it in the session, checks it, and if
something is wrong with it, redirects back to register1.php with error
message saying what needs to be corrected. Say the login name the user
has chosen is saved to the session like this:

$_SESSION['login'] = $_POST['login'];

Now, let's say another part of the application deals with forgotten
passwords. On page resetpw1.php the user enters his user name.
resetpw2.php looks up the secret question for that user in the database
and displays it. User enters the answer to the secret question.
resetpw3.php checks if the answer is correct, saves the user name in the
session ($_SESSION['login'] = $_POST['login'];) and asks the user to
enter the new password. The user enters the new password, and
resetpw4.php takes the user name from the session ($login =
$_SESSION['login']), takes the password from the form data, and updates
the password for that username in the database.

An attacker can first submit data to register2.php (setting the
$_SESSION['login'] to the value of his choice) and then submit data to
resetpw4.php that will take $_SESSION["login"] and change the password
for that account. resetpw4.php trusts the value in $_SESSION['login']
because it thinks that $_SESSION['login'] was created by resetpw3.php,
which verified it by means of secret question.

The problem stems from the fact that same session variable is used by
different processes in the application to store both trusted and
untrusted data.

I have seen this kind of bugs (not only related to logins and passwords,
but other things as well) in several different applications, written by
different development teams in Java and PHP. I suppose it is rather
common problem. These bugs are easy to identify when the source code is
available - just grep for lines where the session variables are
initialized, check where the data comes from, and if it comes from the
user, check where else that session variable is used. They are a lot
more difficult to find with a black-box testing of a web application,
though one can and does stumble upon them accidentally.

As for fixing those bugs, I suppose one approach is having a separate
session variable for each function in the application. For example new
user registration will keep its stuff in $_SESSION["register"]["login"]
and authentication will keep its stuff in $_SESSION["auth"]["login"]

Regards,
Alla Bezroutchko
Scanit

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists