Page 1 of 2

Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 12:41 am
by vspin
In light of new information, I am posting this thread.

In my relentless quest to come up with an alternative solution to prevent Session Hijacking via sniffing network packets without running a web site entirely through HTTPS/SSL, I have come up with a solution, "thinking outside the box", or at least I think I have.

Regardless of whether or not my method increases CPU performance, I'm asking everyone who reads this, am I correct in saying that this an alternative solution?


For this to work, ALL your web pages must look something like this:

Code: Select all

<?php
 
//redirect user back to this page if missing www. in the URL (no http://myweb.com) here.
 
$randomcode = ; //generate random code here
 
?>
 
<html>
<head>
<title>Web Page</title>
</head>
<body>
 
<img src="http://myweb.com/images/logo.gif" border="0" />
 
<img src="http://www.myweb.com/redirect.php?nocache=<?php echo $randomcode ?>" />
<h2>Welcome to myWeb.com!</h2>
</body>
</html>

Your web page URLs must include the www. (e.g. http://www.yourweb.com/page.php).

The next important thing is all other non web page files, such as JS, CSS, DOC, ZIP, GIF, JPG, etc. must have a URL without the www. (e.g. http://yourweb.com/images/logo.gif).

The reason for this is because APACHE/PHP creates different session identifiers for both URLs (verify server settings). This prevents non web page requests passing the sess ID through http. Better yet, create a sub domain (http://upload.yourweb.com/images/logo.gif). Yahoo.com goes one step further and creates a whole new web domain name.


RegenerateIdentifier.php

Code: Select all

<?php
 
  //FAST SSL - Regenerate session identifier
 
  header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
  header("Cache-Control: no-cache");
  header("Pragma: no-cache");
 
  session_start();
  session_regenerate_id(FALSE);
 
?>

redirect.php

Code: Select all

<?php
 
  header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
  header("Cache-Control: no-cache");
  header("Pragma: no-cache");
 
  header('Location: https://www.myweb.com/RegenerateIdentif ... code($_GET["nocache"])));
 
?>

Cons to this method:

Three page requests.
Regenerating Session Identifier with every page request.
The HTTPS request could fail if a user clicks a link or stops or closes their browser too soon.


Basically, here is what happens:

1. User has logged in.
2. User requests http://www.yourweb.com/page.php
3. Page.php sends another request (image) for http://www.yourweb.com/redirect.php?h86d5uij6
4. Redirect.php makes a final secure request (redirect) to https://www.yourweb.com/RegenerateIdent ... =h86d5uij6

The last request changes the users session identifier securely to something only the client and the server know.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 2:35 am
by onion2k
How is the new session id being transmitted to the user? It'll be a cookie in the response header for redirect.php won't it? Eg, not over SSL, unencrypted, and providing no additional security. In fact, just providing the attacker with an additional opportunity to steal it.

Edit: Actually, that depends on whether or not the browser is clever enough to silently follow a 302 redirect, or to follow it and revalidate the security settings. I'd have to test it...

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 2:42 am
by vspin
onion2k wrote:How is the new session id being transmitted to the user? It'll be a cookie in the response header for redirect.php won't it? Eg, not over SSL, unencrypted, and providing no additional security. In fact, just providing the attacker with an additional opportunity to steal it.

Edit: Actually, that depends on whether or not the browser is clever enough to silently follow a 302 redirect, or to follow it and revalidate the security settings. I'd have to test it...
I tested it on IE 6 and it works. No revalidation.

Actually, I tested it on FF, IE7, and Konqueror as well.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 2:50 am
by onion2k
I have to say that surprises me. I would have thought it would revalidate.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 2:53 am
by Bruno De Barros
This is nice man. The third request is nice, and if you just return a 1x1 image (remember on IE 6 it will present itself as a big fat X, remember?), it will be perfect (in my opinion). Nevertheless, (and I am not complaining), this adds more time until the session ID is regenerated, which means more time to attack.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 2:58 am
by vspin
onion2k wrote:I have to say that surprises me. I would have thought it would revalidate.
When I came up with the idea, I was thinking the same thing, but after I tried it, it worked. Surprised me as well.
Bruno De Barros wrote:This is nice man. The third request is nice, and if you just return a 1x1 image (remember on IE 6 it will present itself as a big fat X, remember?), it will be perfect (in my opinion). Nevertheless, (and I am not complaining), this adds more time until the session ID is regenerated, which means more time to attack.
Absolutely. I will make the adjustment. :) Yeah, it adds more time, but still the window of opportunity is still pretty small.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 3:12 am
by Mordred
You're still not paying attention to what's being said and keep trying to solve a non-problem - and keep failing at that.
I won't repeat myself and onion2k why - this is a written media, go and reread it yourself.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 3:16 am
by vspin
Mordred wrote:You're still not paying attention to what's being said and keep trying to solve a non-problem - and keep failing at that.
I won't repeat myself and onion2k why - this is a written media, go and reread it yourself.
Easy with the hostility. :)

I think you're speaking of performance, but I'll go reread what you wrote..

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 3:22 am
by vspin
Mordred wrote:vspin, SSL protects against traffic interception, which is only one way (and the less frequent one at that) of session hijacking. You are not understanding the attack and your protection attempt is inadequate. You also seem to be mixing session hijacking and session fixation, which are related, but different attacks.

The most common way of hijacking a session is through XSS with cookie-stealing javascript. Your options:
1. No XSS holes.
2. IP/User agent locking of the session (not 100% guaranteed to work)
3. Re-authentication for sensitive actions (also helps against CSRF)
Well, I must admit, I'm still confused.. I'm creating a defense against session hijacking via packet sniffing, that's it. I personally cover other hacks as well, but I'm not discussing those.

The only thing I can assume you're talking about is:

<<You are not understanding the attack and your protection attempt is inadequate. You also seem to be mixing session hijacking and session fixation, which are related, but different attacks.>>

Pretty vague response..

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 8:55 am
by onion2k
vspin wrote:Well, I must admit, I'm still confused.. I'm creating a defense against session hijacking via packet sniffing, that's it.
This is the bit that confuses me. You're selling this as a security solution to defend against something, namely session hijacking via packet sniffing. The problem I have though is that SSL is a really good solution to that issue. What you're really trying to sell in this thread is a solution to save bandwidth (by allowing developers to use non-SSL on most things) and CPU time (by not encrypting every page). Your solution really doesn't improve security in any way because a 128bit encrypted SSL connection is just not "sniffable" by any hacker outside of a very small number of government agencies.

So, if we agree that your solution is really a bandwidth and CPU saver rather than a security improvement we have to ask some other questions:

1. Does it really save bandwidth. As covered in the other thread, the answer is likely to be "not much".

2. Does it save any CPU time. It's possible I imagine. I don't know enough about SSL to say. What's certain however is that your solution requires 3 separate page loads for every page the user views. That's going to be a big hit on Apache ... just requesting a page, parsing the request, loading PHP, parsing the script, running it, and sending the user the output might well be more intensive than some encryption.

(By 'sell' I mean 'promote', I don't mean 'ask for money for')

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Tue May 13, 2008 6:36 pm
by vspin
onion2k wrote:This is the bit that confuses me. You're selling this as a security solution to defend against something, namely session hijacking via packet sniffing. The problem I have though is that SSL is a really good solution to that issue. What you're really trying to sell in this thread is a solution to save bandwidth (by allowing developers to use non-SSL on most things) and CPU time (by not encrypting every page). Your solution really doesn't improve security in any way because a 128bit encrypted SSL connection is just not "sniffable" by any hacker outside of a very small number of government agencies.

So, if we agree that your solution is really a bandwidth and CPU saver rather than a security improvement we have to ask some other questions:

1. Does it really save bandwidth. As covered in the other thread, the answer is likely to be "not much".

2. Does it save any CPU time. It's possible I imagine. I don't know enough about SSL to say. What's certain however is that your solution requires 3 separate page loads for every page the user views. That's going to be a big hit on Apache ... just requesting a page, parsing the request, loading PHP, parsing the script, running it, and sending the user the output might well be more intensive than some encryption.

(By 'sell' I mean 'promote', I don't mean 'ask for money for')
<<The problem I have though is that SSL is a really good solution to that issue. What you're really trying to sell in this thread is a solution to save bandwidth (by allowing developers to use non-SSL on most things) and CPU time (by not encrypting every page).>>

Nope. I'm saying this may possibly be an alternative solution (*edit: based on performance). What performance you may gain or lose is still to be determined.


<<Your solution really doesn't improve security in any way because a 128bit encrypted SSL connection is just not "sniffable" by any hacker outside of a very small number of government agencies.>>

Hmm, what if I was using shiflett.org HTTP methods. No improvement? I'm not trying to provide better security than SSL alone.


<<1. Does it really save bandwidth. As covered in the other thread, the answer is likely to be "not much".>>

While I agree it's not much, I have read it can increase as much as 1/3 additional data.


<<2. Does it save any CPU time. It's possible I imagine. I don't know enough about SSL to say. What's certain however is that your solution requires 3 separate page loads for every page the user views. That's going to be a big hit on Apache ... just requesting a page, parsing the request, loading PHP, parsing the script, running it, and sending the user the output might well be more intensive than some encryption.>>

Yes, this is still to be determined. Let's say my method increases CPU resources 50%, but it remains undiscovered. Would you be content with that? Certainly not me.

First things first - regardless of performance, am I correct in saying that this is an alternative solution?

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Wed May 14, 2008 2:38 am
by onion2k
I think I've spotted another potential, albeit unlikely, problem with your solution.

I load a page. This page then requests your "image" which goes to the server and returns a 302 redirect header, which my browser follows to the SSL encrypted script that regenerates the session id. If I click on a link in the page before the redirect has completed then I'd end up sending the current session id over an unencrypted connection. You've introduced a race condition between the user and the image redirect. Clearly a redirect like that should run very quickly but if, for example, I'm on a very high latency connection (satellite link or mobile phone as a modem for example) or my connection is saturated (running bittorrent) then it's not impossible.

Also your solution would break if I browse with images turned off. Normally that's not a problem, but if you're relying on users having images for security... then it is a problem.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Wed May 14, 2008 3:14 am
by vspin
onion2k wrote:I think I've spotted another potential, albeit unlikely, problem with your solution.

I load a page. This page then requests your "image" which goes to the server and returns a 302 redirect header, which my browser follows to the SSL encrypted script that regenerates the session id. If I click on a link in the page before the redirect has completed then I'd end up sending the current session id over an unencrypted connection. You've introduced a race condition between the user and the image redirect. Clearly a redirect like that should run very quickly but if, for example, I'm on a very high latency connection (satellite link or mobile phone as a modem for example) or my connection is saturated (running bittorrent) then it's not impossible.

Also your solution would break if I browse with images turned off. Normally that's not a problem, but if you're relying on users having images for security... then it is a problem.
<<If I click on a link in the page before the redirect has completed then I'd end up sending the current session id over an unencrypted connection.>>

Nice catch. A person could actually stop or close their browser too soon as well. But, we do agree it's a stretch for a hacker. I'll include it as a con.

<<Also your solution would break if I browse with images turned off. Normally that's not a problem, but if you're relying on users having images for security... then it is a problem.>>

Absolutely. I however, use Captcha on my login page, which is just the thing for this.

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Wed May 14, 2008 3:54 am
by vspin
After performance testing, this is what I can only hope the outcome produces:

(*security ratings based on session hijacking via sniffing packets)

Pure HTTPS
#3 Performance Rating
#1 Security Rating

HTTP/HTTPS Hybrid (my method)
#2 Performance Rating
#2 Security Rating

HTTP Methods (IP and/or User Agent)
#1 Performance Rating
#3 Security Rating


Performance is still unknown, but I think we can agree on the security rating (#2).

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Posted: Wed May 14, 2008 4:24 am
by vspin
Bruno De Barros, onion2k,

Instead of RegenerateIdentifier.php being a 1x1 px image, it could also be a small "Seal of Security" or "Hacker Safe" image. You could also add in the Terms of Use to wait for the seal to load. Of course this idea decreases performance slightly.