TalkPHP
 
 
Account Login
Latest Articles
» The basic usage of PHPTAL, a XML/XHTML template library for PHP
» Vulnerable methods and the areas they are commonly trusted in.
» Simple way to protect a form from bot
» The Basics On: How Session Stealing Works
» How to keep your forms from double posting data
IRC Channel
IRC Speech Bubble Join the friendly bunch on IRC...
(#TalkPHP on Freenode)

...Also available via a web interface.

See this thread for information on the TalkPHP Free Hugs Initiative™. Subject to availability.
Associates
Associates
CSS Tutorials
Advertisement
The Basics On: How Session Stealing Works
   Welcome to "The basics on: How Session Stealing Works"!

The Basic method of session stealing
The simplest way to steal a session is to go on the website that you want to steal the session from, and type the following in the address bar:


javascript Code:
prompt('document.cookie value', document.cookie);

You will get a prompt with the contents of your document.cookie variable.

To actually use that data you would use:

javascript Code:
document.cookie = prompt('New document.cookie value', '');

And type what you got from the prompt before into that prompt

How to protect for session stealing
One simple way to protect from session stealing would be to check the sessions internal IP and the users IP.

When you set the session:

php Code:
session_start();
// A bunch of code here
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
// Loads of more code here
 

So on every page after that:

php Code:
session_start();
// A bunch of code here
if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
  $_SESSION = array();
  die('Invalid Session!');
}
// Loads of more code here
 

What this does is reset the session and kill the page load if the IP Address is incorrect.
This is not a fail safe method as many times a day your IP is reset (Unless you have a static IP)
But it does basically protect against session stealing.

Thanks For Reading!
Report this Article
Last 5 Article Reviews Read All Reviews
   httponly
Review added by SneakyWhoami on 09-30-2009
All linked articles in my comment are also available on wikipedia.

For a complementary method with no downside, use an httponly cookie to store the session id.

http://www.owasp.org/index.php/HTTPOnly

That will break your prompt attack in one line of php; javascript won't be able to access the cookie.

Dog Cow is right about the XSS. There are pages on this:
http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

Hiding it in POST doesn't help. You can script a post request cross site in javascript using a hidden iframe and a form's submit() method and target attributes.

Using ajax will only make it harder for legitimate users and easier for attackers if anything. A GET-ted ajax request can be turned into an img src attribute and called from anywhere.

Basically pretty much any element in HTML can be turned into an XSS vector; while it's important to protect your session cookies (which was the whole point of the article) you have to protect your users from other kinds of session hijacking which are easier to pull off (and work for a disgusting number of sites).

Specifically I'm talking about CSRF: http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

Nonces are your protection against CSRF. CSRF is easier than stealing a session cookie so a more urgent form of session protection. Require proof that the user actually owns the session!
   Buiding on from that...
Review added by JaoudeStudios on 07-15-2009
It is more secure to save the session data in a database rather than the usual method which is in the /tmp directory.
   Good advice, but not comprehensive
Review added by Dog Cow on 02-03-2009
Keep in mind that while this article provides good advice, it is not comprehensive.

Imagine this hypothetical situation:

Some web site allows users to delete their own account, at this URL: http://exmple.com/account/delete.php

Now, if user Bob is logged in, he may not ordinarily delete his account. But here's the problem: a malicious user named Joe can set up his own web page, and use Javascript to make an HTTP request to that delete account URL.

If Joe can trick Bob into clicking onto his web page, then that javascript will execute the request, using the Bob's own cookie data, IP address, and browser signature.

The fix? Implement a token/hash in sensitive URLs, and make this hash unique for each user and require it in order to access potentially "dangerous" URLs. This means that malicious user Joe will have a lot harder time guessing what the token is.

Simply substituting the POST method without using a hash is NOT a fix. Javascript can execute GET and POST requests in less than 10 lines of code.
   .....
Review added by nightowl on 01-07-2009
a) it's perfectly possible to be on the net at the same time with different IP addresses. Big LAN's often have an internal IP, and use several outbound IP's in a sort of round robin. You'd accuse somebody of stealing a session while it's in fact a correct user

b) you claim it's that easy, but your first step requires access to the person's computer you want to steal the session from ... and if you have access to his computer, why not just use his computer then? ;)
   hmm
Review added by t3st on 11-17-2008
is there a way to just save the mac address rather than the ip address??

All times are GMT. The time now is 04:20 PM.

 
     

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.1.0
Inactive Reminders By Icora Web Design