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

Post Reply
abalfazl
Forum Commoner
Posts: 71
Joined: Mon Sep 05, 2005 10:05 pm

Session hijacking

Post by abalfazl »

Hello
from this thread:

http://www.sitepoint.com/forums/showthr ... ion+hijack

ini_set('session.referer_check', 'yahoo.com');

define('UA_SEED');

session_start();

if(!isset($_SESSION['created'])){

session_regenerate_id();

$_SESSION['created'] = TRUE;

}

if(!isset($_SESSION['user_agent'])){

$_SESSION['user_agent'] = md5($_SERVER['HTTP_USER_AGENT'] . UA_SEED);

}

else{

if($_SESSION['user_agent'] != md5($_SERVER['HTTP_USER_AGENT'] . UA_SEED)){

Echo "There was an error with the information your browser provided this website<br>";

Echo "Please go here and try logging in again<br>";

Echo "Error code: 89101311";

}

}

As you see,this code checks HTTP_USER_AGENT ,I see that it is recommended that use IP Identification in order to prevent session hijacking,

But....

I checked this site:
http://shiflett.org/articles/session-hijacking

There is a very interesting comment there:

Couple of questions/comments:

1) I think if a hacker is hell-bent, then he can easily create a program to do the following:

- Sniff server responses and identify ones that contain a sessionid, last issued token etc.

- generate a server request with the sniffed sessionid, token

- it doesn't matter even if these are encrypted. Its the server's job to decrypt them. The hacker just has to send back the encrypted values.

This can be easily done within milliseconds with a powerful dual core proc. So it easily beats the 3 sec. window

2) I analyzed Orkut's authentication/authorization procedure:

- Use HTTPS to transmit username/password

- Send back some cookies (over SSL), once authenticated

- Redirect to some HTTP page

After this stage, all authentication is done through few cookies.

These cookies are authorized for the following URL's

- http://www.google.com/accounts (cookies rememberme, SID)

- google.com/ (cookie LSID)

- orkut.com/ cookies (_utma, _utmb, _utmz)

If I delete even 1 of them, the authentication fails.

However, I am just clicking on http://www.orkut.com/... URLs. So only the last cookie should be useful and deleting the rest should not have any effect. Also, there is no redirection happening b/w orkut & google. So I fail to see why deleting the Google cookies are having any effect for subsequent requests.

Anyway, the point of illustrating Orkut's example is the following:

- Orkut does not use any javascript for authentication. Everything works just fine even if you've disable javascript.

So no 3 second windows etc. can be implemented.

- Post initial authentication (through username/password over HTTPS), all authentication is taking place using cookies over HTTP.

Now, the only thing that could distinguish b/w two requests with similar cookies are the following:

1) HTTP Headers (USER-AGENT, ACCEPT etc.)

2) IP Address.

- The first one is really easy to duplicated.

- IP spoofing is not impossible, but extremely hard. But it becomes a child's play when the victim & hacker are both behind a firewall (since Orkut/Google cannot distinguish b/w their IP's).

So how do they distinguish b/w the hacker and the victim? Orkut is backed by Google, which has hundreds of PhD's. So in all likeliness, they use some mechanism which is extremely hard to crack. How do they do it???

Any thoughts/suggestions?

Thanks,

Any thoughts/suggestions?
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Session hijacking

Post by alex.barylski »

On a shared host, storing session's in a database is your best bet, but then there is the issue of other users being able to see your database details and still steal your sessions.

Most attacks in this case, likely come from the outside world not other users on your system -- unless they are retraded because I imagine most hosting companies have policies preventing such abuse.

To prevent session fixation, you simply need to regenerate the ID on each request and preferably store session data in cookies -- but if the user disables cookies this is again a problem.

On a dedicated host session regeneration is about as good as your going to get. Still possible to hijack the session, if someone sniffed the traffic and used your new ID before you did.

In which case, if your that paranoid, have a system in place that haults everything when the same ID is used twice and email the admin to investigate immediately.

Using an IP in conjunction with the SESSION is pointless. If the hacker sniffed your traffic and stole your session ID they can also get your IP address and simply pass that along as well.
abalfazl
Forum Commoner
Posts: 71
Joined: Mon Sep 05, 2005 10:05 pm

Re: Session hijacking

Post by abalfazl »

Hello!
In which case, if your that paranoid, have a system in place that haults everything when the same ID is used twice and email the admin to investigate immediately.
How?May you explain more?Please give me example code.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Session hijacking

Post by alex.barylski »

Good question. :P

Not as easy as I thought as there are no session_check() functions. However it should still be doable you would have to re-implement the session storage routines though so you have direct access to the session ID's and data.

Basically the idea is this:

1. Session is regenerated each request
2. When request is made you check the SID stored in COOKIE or GET
3. If the SID is still in the database (or if you have access to session directory say on dedicated host) your good to go. If the SID is no longer available, it's expired (which could be a problem -- you need more checking to circumvent false positives here) or someone has tried to used someone else's session (ie: hijacked) and the system should go into panic mode.

As for code, sorry. Far to elaborate of a solution is required to just offer demo code. The above should be enough to get you started. Go read the PHP docs on sessions:

http://ca3.php.net/manual/en/function.s ... andler.php
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Session hijacking

Post by Mordred »

This does not prevent hijacking the latest (and correct) SID and using it before the user does.

It is therefore unneeded to regenerate the id on every requests, do it only when the user changes his authorization status. It prevents session fixation, which is a different attack. Don't forget to set the $delete_old_session = TRUE parameter.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Session hijacking

Post by alex.barylski »

Actually session hijacking is a common term used describe session theft in general ;)

http://en.wikipedia.org/wiki/Session_hijacking
This does not prevent hijacking the latest (and correct) SID and using it before the user does.
Regardless of whether the SID is retreived through XSS, packet sniffing or direct theft by looking up where sessions are stored on the physical HDD (common for shared hosts) the SID is less likely to be stolen or used effectively if it's regenerated on each request.

If an attacker steals my SID and uses it to check my bank account...while I'm reading...if the system at least alerts me and the system admins when I make another request and the system determines that my SID was already used and thus an attacker has likely used it...what exactly is the alternative, short of using SSL on each request???
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Session hijacking

Post by Mordred »

Hockey wrote:Actually session hijacking is a common term used describe session theft in general
Then why do you discuss only fixation?
Regardless of whether the SID is retreived through XSS, packet sniffing or direct theft by looking up where sessions are stored on the physical HDD (common for shared hosts) the SID is less likely to be stolen or used effectively if it's regenerated on each request.
Untrue. Whoever has a method of stealing the SID will use it immediately for his purpose, leaving the original session owner in an invalid state. True, he will be detected, but he would not be hampered to use it.
If an attacker steals my SID and uses it to check my bank account...while I'm reading... (snip) ... what exactly is the alternative, short of using SSL on each request???
Two things:
1. SSL prevents sniffing the traffic, and therefore only one mechanism of SID stealing
2. Apart from sniffing, SID stealing works with SSL as well, as it is something that travels from endpoint to endpoint.
if the system at least alerts me and the system admins when I make another request and the system determines that my SID was already used
Now this is something important, and a key feature in any security system. Without proper monitoring and reaction mechanisms, a system will not be secure. Sadly, many security writings omit this and concentrate solely on prevention.
abalfazl
Forum Commoner
Posts: 71
Joined: Mon Sep 05, 2005 10:05 pm

Re: Session hijacking

Post by abalfazl »

if the system at least alerts me and the system admins when I make another request and the system determines that my SID was already used
A database that registers all SID and if a SID is used for 2 users alerts,What do you think?

how exactly do you plan to determine if the SID is being used by a second user?
abalfazl
Forum Commoner
Posts: 71
Joined: Mon Sep 05, 2005 10:05 pm

Re: Session hijacking

Post by abalfazl »

Can this code prevent session hijacking?

Code: Select all

 
 
<?php
 
 
 
/** 
 
This is the token that should be generated when originally authenticating the user, and stored in the session 
 
*/
 
$sessionToken = sha1('saltdefinedhere' . $_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']);
 
$_SESSION['token'] = $sessionToken;
 
/**
 
This section validates the user on the return to the site, to a certain extent
 
*/
 
if($_SESSION['token'] !== sha1('saltdefinedhere' . $_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']))
 
{
 
  $_SESSION = array();
 
  header('location: login.php'); //send them to wherever they must login, gracefully
 
}
 
 
 
?>
 
 
Post Reply