Prevent Session Hijacking with HTTP and a little HTTPS

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

vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
Last edited by vspin on Wed May 14, 2008 3:27 am, edited 3 times in total.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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...
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post by onion2k »

I have to say that surprises me. I would have thought it would revalidate.
Bruno De Barros
Forum Commoner
Posts: 82
Joined: Mon May 12, 2008 8:41 am
Location: Ireland

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
Last edited by vspin on Tue May 13, 2008 3:13 am, edited 1 time in total.
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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..
Last edited by vspin on Tue May 13, 2008 3:37 am, edited 1 time in total.
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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..
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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')
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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?
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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).
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Prevent Session Hijacking with HTTP and a little HTTPS

Post 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.
Post Reply