Page 1 of 2
Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 12:09 am
by vspin
To prevent session hijacking, I have come up with an idea that does not require SSL on every page, which should improve performance. Well, sort of..
All client's browsers must allow IFrames for this to work. Note that some pages such as login.php, changepassword.php, etc. must be run with SSL.
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);
?>
page.php
Code: Select all
<html>
<head>
<title>Web Page</title>
</head>
<body>
<iframe src ="https://www.myweb.com/RegenerateIdentifier.php" scrolling="no" width="0" height="0" />
<h2>Welcome to myWeb.com!</h2>
</body>
</html>
When you run
http://www.myweb.com/page.php in your browser, the IFrame loads
https://www.myweb.com/RegenerateIdentifier.php, which regenerates your session identifier securely with much less unnecessary encryption.
Would this work? And, does it provide better performance?
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 2:05 am
by John Cartwright
Regenerating the session ID shouldn't be done on every request, only on privilege changes such as login, password change, etc. Secondly, why do you require an iframe? Why not simply include() the file? Thirdly, the use of SSL is absolutely recommended to prevent session hijacking because it encrypts the actual transmission, and in no way is this technique a substitute.
Sorry to say, your solution is not a solution at all.
See
http://shiflett.org/articles/session-fixation
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 3:00 am
by vspin
Jcart wrote:Regenerating the session ID shouldn't be done on every request, only on privilege changes such as login, password change, etc. Secondly, why do you require an iframe? Why not simply include() the file? Thirdly, the use of SSL is absolutely recommended to prevent session hijacking because it encrypts the actual transmission, and in no way is this technique a substitute.
Sorry to say, your solution is not a solution at all.
See
http://shiflett.org/articles/session-fixation
<<Regenerating the session ID shouldn't be done on every request, only on privilege changes such as login, password change, etc.>>
Yeah, I agree, but only because it will cause problems if someone clicks back on their browser. And, I believe the new session identifier would ONLY apply to the IFrame..
<<Secondly, why do you require an iframe? Why not simply include() the file?>>
I think you're misunderstanding the objective here. You would still need to make a secure request. How would including the file encrypt the new session identifier? I'm only encrypting what's important.
<<Thirdly, the use of SSL is absolutely recommended to prevent session hijacking because it encrypts the actual transmission, and in no way is this technique a substitute.>>
I didn't say my technique was a substitute for SSL. The idea is to use SSL as minimal as possible creating better performance. I know I don't want to run my entire site through SSL! As far as I know, you can't run some pages secure and some not. As soon as you run a non secure page your session identifier is available in plain text ready to be sniffed.
These methods are not reliable and more open to spoofs. Especially with AOL users.
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 4:27 am
by Apollo
And besides, SSL should hardly cost performance.
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 5:27 am
by vspin
Apollo wrote:And besides, SSL should hardly cost performance.
I disagree. Not to mention SSL eats up bandwidth, which is something many of us don't have enough of. Look at ebay.com. They managed a compromise to use both.
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 5:34 am
by onion2k
Why would an SSL encrypted page use any more bandwidth than an unencrypted page?
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 5:35 am
by vspin
onion2k wrote:Why would an SSL encrypted page use any more bandwidth than an unencrypted page?
Because the page/data is encrypted and not in a simplified plain text form.
Image this:
"Welcome to my brand new web site!!"
Looking something like this:
"00dc1cd7792d294b74651f1ccc736128 01c391424ae04b81edf483fb7250ab62 014e0ea90e1340cfcd607347571dd4d6"
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 6:51 am
by Apollo
Other than padding bytes, an encrypted piece of data is just as large as its original.
Perhaps you're confusing encryption with (long) hash codes?
Re: Secure pages with less encryption and better performance..?
Posted: Tue May 06, 2008 12:37 pm
by Mordred
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.
Re: Secure pages with less encryption and better performance..?
Posted: Wed May 07, 2008 3:35 am
by vspin
Thank you guys for your help and please excuse me if my understanding is too vague. I'm trying to fill in the holes.

)
<<Other than padding bytes, an encrypted piece of data is just as large as its original.
Perhaps you're confusing encryption with (long) hash codes?>>
How can that be? I used something like this to make this determination:
http://www-cs-students.stanford.edu/~tjw/jsbn/rsa.html
Are you saying if I send 68KB of none encrypted data to a client, it would be nearly the same size as sending encrypted data? I'm not saying it's not true, cause I really have no clue, which is why I'm seeking your help. How is this done?
<<vspin, SSL protects against traffic interception, which is only one way (and the less frequent one at that) of session hijacking.>>
Yes, I know, but it makes me feel better if I can prevent it.

))
<<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.>>
My understanding of session hijacking is that an attacker sniffs out HTTP packets going to and from the server, identifies the session identifier and takes it as his own..?
I think your suggesting I'm confused with session fixation because I'm always regenerating the session identifier..? I am regenerating the session identifier through https/SSL because the initial request is through http. Well, any way it doesn't really matter because constantly regenerating the session identifier is going to cause problems through an IFrame and with the back button.
I am looking for a way to be able to use http and https less frequently and still prevent session hijacking through the network traffic.
Re: Secure pages with less encryption and better performance..?
Posted: Wed May 07, 2008 5:18 am
by Mordred
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)
Re: Secure pages with less encryption and better performance..?
Posted: Wed May 07, 2008 5:37 am
by vspin
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)
I do have #1 covered. I don't really like #2.
I take it back with regard to my method not being adequate!
I have revised my code below, which requires javascript enabled browsers.
If this method is in your opinion not adequate protection against session hijacking via packet sniffing, then please explain why. Put yourself in a hacker's shoes.
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);
?>
page.php
Code: Select all
<html>
<head>
<title>Web Page</title>
<script type="text/javascript">
window.onload = function() {
security = new Image();
security.src = "https://www.myweb.com/RegenerateIdentifier.php";
}
</script>
</head>
<body>
<h2>Welcome to myWeb.com!</h2><br />
</body>
</html>
Here's the scenario: an Administrator has just logged into the web site. He keeps reloading page.php in his browser through HTTP and later allows his session to expire without logging out. How are you going to obtain the necessary session identifier to hijack the session?

Re: Secure pages with less encryption and better performance..?
Posted: Wed May 07, 2008 5:08 pm
by Apollo
vspin wrote:How can that be? I used something like this to make this determination:
http://www-cs-students.stanford.edu/~tjw/jsbn/rsa.html
Are you saying if I send 68KB of none encrypted data to a client, it would be nearly the same size as sending encrypted data? I'm not saying it's not true, cause I really have no clue, which is why I'm seeking your help. How is this done?
Yes, the data would nearly (or in case of 68KB which is a multiple of all commonly used block sizes, probably
exactly) be the same size.
If you look at that example site and encrypt some random test strings, you'll notice that the encrypted size does not become larger when you enter longer strings. The length of the encrypted data is obviously a result of padding here.
(by the way, this particular site only allows encrypting strings up to one block size in length, i.e. max 512 or 1024 bits - note that such a size limitation of only one block is *not* common)
Encryption typically occurs in blocks, for example 512 bits. Then when you encrypt a piece of data, it's padded up to the next multiple of the block size. When encrypting anything between 1 and 512 bytes (and using an encryption method with block size 512), the encrypted data would be 512 bytes. Anything between 513 and 1024 bytes would become 1024 bytes, etc.
Re: Secure pages with less encryption and better performance..?
Posted: Wed May 07, 2008 5:54 pm
by vspin
Apollo wrote:
Yes, the data would nearly (or in case of 68KB which is a multiple of all commonly used block sizes, probably exactly) be the same size.
If you look at that example site and encrypt some random test strings, you'll notice that the encrypted size does not become larger when you enter longer strings. The length of the encrypted data is obviously a result of padding here.
(by the way, this particular site only allows encrypting strings up to one block size in length, i.e. max 512 or 1024 bits - note that such a size limitation of only one block is *not* common)
Encryption typically occurs in blocks, for example 512 bits. Then when you encrypt a piece of data, it's padded up to the next multiple of the block size. When encrypting anything between 1 and 512 bytes (and using an encryption method with block size 512), the encrypted data would be 512 bytes. Anything between 513 and 1024 bytes would become 1024 bytes, etc.
Apollo,
Awesome! Exactly what I was trying to figure out. Thank you.

Re: Secure pages with less encryption and better performance..?
Posted: Wed May 07, 2008 10:18 pm
by vspin
Actually, I have found a hole in my method. Any http request (such as an image) coming after the https request would reveal the new session identifier. The https request would have to be the very last request..
------------------
EDIT (fixed)
------------------
I fixed my method above by changing:
<script type="text/javascript" src="
https://www.myweb.com/RegenerateIdentif ... "></script>
to the following:
<script type="text/javascript">
window.onload = function() {
security = new Image();
security.src = "
https://www.myweb.com/RegenerateIdentifier.php";
}
</script>