Secure pages with less encryption and better performance..?

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

Secure pages with less encryption and better performance..?

Post 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?
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Re: Secure pages with less encryption and better performance..?

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

Re: Secure pages with less encryption and better performance..?

Post 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.
Last edited by vspin on Tue May 13, 2008 5:26 am, edited 1 time in total.
User avatar
Apollo
Forum Regular
Posts: 794
Joined: Wed Apr 30, 2008 2:34 am

Re: Secure pages with less encryption and better performance..?

Post by Apollo »

And besides, SSL should hardly cost performance.
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Secure pages with less encryption and better performance..?

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

Re: Secure pages with less encryption and better performance..?

Post by onion2k »

Why would an SSL encrypted page use any more bandwidth than an unencrypted page?
vspin
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Secure pages with less encryption and better performance..?

Post 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"
User avatar
Apollo
Forum Regular
Posts: 794
Joined: Wed Apr 30, 2008 2:34 am

Re: Secure pages with less encryption and better performance..?

Post 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?
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Secure pages with less encryption and better performance..?

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

Re: Secure pages with less encryption and better performance..?

Post 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.
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Secure pages with less encryption and better performance..?

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

Re: Secure pages with less encryption and better performance..?

Post 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? :)
Last edited by vspin on Thu May 08, 2008 4:43 am, edited 2 times in total.
User avatar
Apollo
Forum Regular
Posts: 794
Joined: Wed Apr 30, 2008 2:34 am

Re: Secure pages with less encryption and better performance..?

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

Re: Secure pages with less encryption and better performance..?

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

Re: Secure pages with less encryption and better performance..?

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