Question about session hijacking

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Swede78
Forum Contributor
Posts: 198
Joined: Wed Mar 12, 2003 12:52 pm
Location: IL

Question about session hijacking

Post by Swede78 »

When a session is hijacked, does this just mean that the hijacker now has access to the hijackee's webpages that only thier session allows? Or can the hijacker actually manipulate the session data? I have not yet found any article mention that.

The reason I ask is that I wonder if it's necessary to recalculate all critical data before storing to a database, rather than only calculate data the first time it's needed (and when user makes changes) and keep it in a session until ready to put in the database.
malcolmboston
DevNet Resident
Posts: 1826
Joined: Tue Nov 18, 2003 1:09 pm
Location: Middlesbrough, UK

Post by malcolmboston »

they take the persons 'identity' online.

anything the user could do, they can now do, such as login to priviliged area, post under there username etc etc
User avatar
hawleyjr
BeerMod
Posts: 2170
Joined: Tue Jan 13, 2004 4:58 pm
Location: Jax FL & Spokane WA USA

Post by hawleyjr »

A good but not 100% accurate way to prevent session hijacking is to do an IP / Browser or Cookie check when you call the session vars.
Swede78
Forum Contributor
Posts: 198
Joined: Wed Mar 12, 2003 12:52 pm
Location: IL

Post by Swede78 »

Ok, so they couldn't actually manipulate stored session data (except if they now have access to webpages that allows them to do so). The data that a hijacker would find in another user's profile on my website is not critically sensitive. But, don't get me wrong, I take the security of that information very seriously. My concern is less about a hijacker finding a user's information, then it is about a hijacker manipulating session data to be something it shouldn't be, right before it's stored in the database. Or even a user manipulating their own session data, is that possible?


Example Scenerio:
If I have page1.php which calculates $A + $B = $_SESSION['C'], and page2.php puts $_SESSION['C'] in the database, I will not have to worry about $_SESSION['C'] being changed by a hijacker somehow. Right? What I've done in the past is recalculate $A + $B on page2.php, instead of using $_SESSION['C']. But, if storing data in sessions is safe, I want to avoid using up valuable server resources because my calculations are getting much more complicated than $A + $B.

As for the IP checking... what if their IP changes during a session? I believe that is possible.
malcolmboston
DevNet Resident
Posts: 1826
Joined: Tue Nov 18, 2003 1:09 pm
Location: Middlesbrough, UK

Post by malcolmboston »

Swede78 wrote: As for the IP checking... what if their IP changes during a session? I believe that is possible.
it is possible yes but so what, get them to log back in, it adds an extra dimension to your security at a slight cost that 99% of your users will never experience
Swede78
Forum Contributor
Posts: 198
Joined: Wed Mar 12, 2003 12:52 pm
Location: IL

Post by Swede78 »

it is possible yes but so what, get them to log back in, it adds an extra dimension to your security at a slight cost that 99% of your users will never experience
I use sessions for much more than storing log-in information. I have a lot of multi-page forms that rely on sessions. I would be quite annoyed if I had to re-login and start over after filling out multiple pages of information for 15 minutes. I wouldn't want even 1% of my users to experience that.

Maybe for certain sites, I would accept that inconvenience in trade of security.


But, back to my original topic... any reason to worry about critical session data being manipulated?
User avatar
shiznatix
DevNet Master
Posts: 2745
Joined: Tue Dec 28, 2004 5:57 pm
Location: Tallinn, Estonia
Contact:

Post by shiznatix »

i don't believe it is possible for the user to change the session data, only to steal a users existing session but not change that users session information

ie they cant take $_SESSION['value'] that = 1 and change it to $_SESSION['value'] to = 2. i really dont believe this is possible
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post by Buddha443556 »

Swede78 wrote:But, back to my original topic... any reason to worry about critical session data being manipulated?
If that critical data depends on the user input and the session has been hijacked then wouldn't the answer be yes?

If $A or $B are supplied by the user then $_SESSION['C'] which equals $A + $B could be corrupted by a hijacker?
Swede78 wrote:I would be quite annoyed if I had to re-login and start over after filling out multiple pages of information for 15 minutes.
If the data is critical then challenge the user for their password. It's just one more field to fill out on the last page of the form. No need for the username you should know that already. Your not logging them in. Your just confirming their identity before they perform a critical operation.
Swede78
Forum Contributor
Posts: 198
Joined: Wed Mar 12, 2003 12:52 pm
Location: IL

Post by Swede78 »

If that critical data depends on the user input and the session has been hijacked then wouldn't the answer be yes?

If $A or $B are supplied by the user then $_SESSION['C'] which equals $A + $B could be corrupted by a hijacker?
Sorry, I should have been more specific. The data that I'm concerned about storing as a session (in my example $A + $B) is not derived from any user input. I understand that if a hijacker takes over a session, they would be able to access/manipulate anything that the hijacked user would be able to. And therefore, as Buddha suggests also, I do require to supply the password when the user wishes to change any personal information. I also send an email notification that changes have been made, to both old and new addresses.
i don't believe it is possible for the user to change the session data, only to steal a users existing session but not change that users session information
That anaswers my question then. I'm not going to recalculate $A + $B multiple times, when I know $A + $B does not change, out of paranoia. I suppose a hacker could get in the server, find the session file and change some values, but then I got more serious issues :)

Thank you all for the responses!
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

This is how i build a "fingerprint" of a visitor..

Code: Select all

// get the fingerprint of the user
    function getFingerprint()
    {
        $fingerprint = $this->secret;
        if (array_key_exists('HTTP_USER_AGENT', $_SERVER)) 
        {
            $fingerprint .= $_SERVER['HTTP_USER_AGENT'];
        }
        if (array_key_exists('HTTP_ACCEPT_CHARSET', $_SERVER))
        {
            $fingerprint .= $_SERVER['HTTP_ACCEPT_CHARSET'];
        }
        $fingerprint .= session_id();
        $fingerprint = md5($fingerprint);
        return $fingerprint;
    }
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

malcolmboston wrote:
Swede78 wrote: As for the IP checking... what if their IP changes during a session? I believe that is possible.
it is possible yes but so what, get them to log back in, it adds an extra dimension to your security at a slight cost that 99% of your users will never experience
I'd say that statistic is 99% pulled out of the air.

A *large* number of users go through proxies, concentrators, and web content engines that end up changing their IP address during a session. Entire *countries* have their access forced through such devices, and to say that only affects 1% of the population is a little inaccurate in my experience. (Of course, if your webapp market is 99% people that use static IP addresses in the US only, then yes, it would be 99%)

In my experience, its a significant amount - over 15% for people playing BNT, TKI, and other various games I've contributed to.

A much more reliable method to preventing session hijacking is to use a one-time pad. By sending a one-time secret to the user, and forcing them to respond with a different secret (password?) hashed with that one-time secret, you seriously reduce the possibility of session hijacking.

Now the attacker has to get a working session cookie in the narrow window of time that a user is logged in, which quite literally may only be 10 minutes out of a day (1440 minutes, or less than 1% of the time).

Just a thought.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

timvw wrote:This is how i build a "fingerprint" of a visitor.
Very nice. If I may make one suggestion, you might want to consider adding some bit of information that never leaves the server - a secret string of some sort.

For example, if you append 'SHIFLETT' to your fingerprint before you hash it, then an attacker who is able to snoop a user's request (and has access to all of the HTTP headers) is more unlikely to be able to reproduce the fingerprint. Of course, the attacker may be able to snoop a user's request sent to your site, exposing the fingerprint, but this particular risk can be mitigated with SSL.

Hope that helps.
weierophinney
Forum Newbie
Posts: 1
Joined: Sat Jun 25, 2005 7:13 pm
Location: Vermont, USA

Post by weierophinney »

shiflett wrote:
timvw wrote:This is how i build a "fingerprint" of a visitor.
Very nice. If I may make one suggestion, you might want to consider adding some bit of information that never leaves the server - a secret string of some sort.
The fingerprint starts with:

Code: Select all

$fingerprint = $this->secret;
and then builds the fingerprint by appending to that string. Isn't that what you're describing? Or did I miss something?
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

weierophinney wrote:The fingerprint starts with:

Code: Select all

$fingerprint = $this->secret;
and then builds the fingerprint by appending to that string. Isn't that what you're describing? Or did I miss something?
You didn't miss anything - I did. :-)
bsdguru
Forum Newbie
Posts: 1
Joined: Mon Jun 27, 2005 5:46 am

Post by bsdguru »

timvw wrote:

Code: Select all

// get the fingerprint of the user
    function getFingerprint()
    {
        $fingerprint = $this->secret;
        if (array_key_exists('HTTP_USER_AGENT', $_SERVER)) 
        {
            $fingerprint .= $_SERVER['HTTP_USER_AGENT'];
        }
        if (array_key_exists('HTTP_ACCEPT_CHARSET', $_SERVER))
        {
            $fingerprint .= $_SERVER['HTTP_ACCEPT_CHARSET'];
        }
        $fingerprint .= session_id();
        $fingerprint = md5($fingerprint);
        return $fingerprint;
    }
Chris, what are your recommendations for variables to include in a "vistor fingerprint"? Users can modify their HTTP_USER_AGENT, HTTP_ACCEPT_CHARSET can change between requests, etc. AOL for example use weirdly configured proxy servers to proxy web traffic so AOL's users web requests always come from random IP's of AOL's various proxy servers.
Post Reply