Session hijacking
Posted: Tue Jul 22, 2008 1:27 pm
Hello
from this thread:
http://www.sitepoint.com/forums/showthr ... ion+hijack
But....
I checked this site:
http://shiflett.org/articles/session-hijacking
There is a very interesting comment there:
Any thoughts/suggestions?
from this thread:
http://www.sitepoint.com/forums/showthr ... ion+hijack
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,
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";
}
}
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?