Secure pages with less encryption and better performance..?
Moderator: General Moderators
-
Bruno De Barros
- Forum Commoner
- Posts: 82
- Joined: Mon May 12, 2008 8:41 am
- Location: Ireland
Re: Secure pages with less encryption and better performance..?
I believe I understand what vspin wants to do. By using this method he created, he makes sure that the session can only last one page view, and when he finishes loading the page, it regenerates, so it's hard for anyone listening to that page request, because what they will read is an old session ID.
For people intercepting the communication, when they receive the contents of the page, the session ID they see will be the old one, as the SSL session regeneration will occur and generate a new session ID.
All this prevents is people getting the session ID just by intercepting the communications. It doesn't protect POST data nor your information, but it protects your session ID.
But if I had an SSL certificate, I would rather have my whole website SSL'ed.
For people intercepting the communication, when they receive the contents of the page, the session ID they see will be the old one, as the SSL session regeneration will occur and generate a new session ID.
All this prevents is people getting the session ID just by intercepting the communications. It doesn't protect POST data nor your information, but it protects your session ID.
But if I had an SSL certificate, I would rather have my whole website SSL'ed.
Re: Secure pages with less encryption and better performance..?
Surely it'll only be the 'old' session id if the user has loaded a page since their session id has been intercepted. If the attacker loads a page before the user loads a new page then the session id will change for the attacker and the user will be left with an out of date session id.. and be kicked out of the site.Bruno De Barros wrote:For people intercepting the communication, when they receive the contents of the page, the session ID they see will be the old one, as the SSL session regeneration will occur and generate a new session ID.
Eg
User loads page and gets a new session with an id of 123
User sends 123 and loads a new page and gets session 124
User sends 124 and loads a third page and gets session 125 - attacker intercepts this id.
User sends 125 and loads a fourth page and gets session 126 - attacker sends 125 a moment later, session is out of date so page load fails
User sends 126 and loads a fifth page and gets session 127 - attacker intercepts this id.
Attacker sends 127 and loads a new page and gets session 128 - user sends 127 a moment later, session is out of date so page load fails.
Attacker steals all of the users money.
-
Bruno De Barros
- Forum Commoner
- Posts: 82
- Joined: Mon May 12, 2008 8:41 am
- Location: Ireland
Re: Secure pages with less encryption and better performance..?
Actually, it would be:User loads page and gets a new session with an id of 123
User sends 123 and loads a new page and gets session 124
User sends 124 and loads a third page and gets session 125 - attacker intercepts this id.
User sends 125 and loads a fourth page and gets session 126 - attacker sends 125 a moment later, session is out of date so page load fails
User sends 126 and loads a fifth page and gets session 127 - attacker intercepts this id.
Attacker sends 127 and loads a new page and gets session 128 - user sends 127 a moment later, session is out of date so page load fails.
Attacker steals all of the users money.
User sends 123 and loads a new page and gets session 124.
User sends 124.
Attacker gets 124, while the page is loading, and sends a request to get 125.
User gets unknown, because 124 was regenerated, so the session just starts from new.
Attacker continues, and steals all of the user's money.
Because the attacker can't intercept 125, because the user only "gets" session IDs with SSL.
But I get the point.
Nevertheless, you must admit, it is quite hard, unless the attacker is between the server and the client (as in proxy), because the attacker needs to read the request headers BEFORE the HTML is received and processed by the browser. As soon as it's processed by the browser, it becomes useless. Unless the hacker codes some kind of virus to do that, and then mail the new session ID to the hacker.
Re: Secure pages with less encryption and better performance..?
Bruno De Barros,
Thanks for seeing what I am doing.
) Yeah, for pages such as login, registration, etc. you'd want them to be a HTTPS/SSL page. I was trying to come up with a way to use less HTTPS. Look at it this way, if you are trying to prevent session hijacking via packet sniffing, when you use HTTP/SSL entirely, you also need to make sure all your IMG, ZIP, DOC, JS, CSS, etc. source files are through HTTPS/SSL as well (like PayPal.com).
By the way, I updated my method, which no longer requires Javascript and is much more reliable!:
For this to work, ALL your web pages must look something like this:
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
Thanks for seeing what I am doing.
By the way, I updated my method, which no longer requires Javascript and is much more reliable!:
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" />
<div id="ssl" style="display: none;"><img src="https://www.myweb.com/RegenerateIdentifier.php?nocache=<?php echo $randomcode ?>" /></div>
<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);
?>
Last edited by vspin on Mon May 12, 2008 4:38 pm, edited 1 time in total.
Re: Secure pages with less encryption and better performance..?
Perhaps I'm failing to understand some complexity in vspin's idea here but all I can see it doing is changing the session id on every page load by requesting an 'image' that changes the user's session id. Why does is matter where the attacker is intercepting the id? They could be intercepting it at the server (relatively easy in a shared environment via a comprised script or root account), in the middle (hard, protected via SSL) or at the client PC (relatively easy via malware, trivial with physical access). The fact they're requesting it on every page means there's actually more chance of an automated attack working ... there's going to be a lot more data to work with. Sites that are using this technique will stand out like a shining beacon to anyone watching network traffic. How does this provide more security than changing the session id when the page is generated? What does the 'image' bit add? What's wrong with putting session_regenerate_id(FALSE); in some of your pages as they're generated?
Re: Secure pages with less encryption and better performance..?
onion2k,onion2k wrote:Perhaps I'm failing to understand some complexity in vspin's idea here but all I can see it doing is changing the session id on every page load by requesting an 'image' that changes the user's session id. Why does is matter where the attacker is intercepting the id? They could be intercepting it at the server (relatively easy in a shared environment via a comprised script or root account), in the middle (hard, protected via SSL) or at the client PC (relatively easy via malware, trivial with physical access). The fact they're requesting it on every page means there's actually more chance of an automated attack working ... there's going to be a lot more data to work with. Sites that are using this technique will stand out like a shining beacon to anyone watching network traffic. How does this provide more security than changing the session id when the page is generated? What does the 'image' bit add? What's wrong with putting session_regenerate_id(FALSE); in some of your pages as they're generated?
You are not fully understanding the concept.
<<all I can see it doing is changing the session id on every page load by requesting an 'image' that changes the user's session id>>
Note that the request is HTTPS. I think this is what you are missing.
<<Why does is matter where the attacker is intercepting the id? They could be intercepting it at the server (relatively easy in a shared environment via a comprised script or root account), in the middle (hard, protected via SSL) or at the client PC (relatively easy via malware, trivial with physical access).>>
I am just putting a base down. You can prevent the first suggestion by placing a cookie on the user's machine during any request (or by constantly changing it during the secure request like the in-memory cookie). My method covers the second suggestion. The third suggestion is impractical for anyone. I also recommend placing a token/input in html forms.
<<The fact they're requesting it on every page means there's actually more chance of an automated attack working ... there's going to be a lot more data to work with. Sites that are using this technique will stand out like a shining beacon to anyone watching network traffic.>>
It doesn't matter. The important data goes through HTTPS/SSL.
<<How does this provide more security than changing the session id when the page is generated?.. ..What's wrong with putting session_regenerate_id(FALSE); in some of your pages as they're generated?>>
Because HTTP requests are not secure.
<<What does the 'image' bit add?>>
The most vital part of the concept. You are requesting an HTTPS PHP page through it, which regenerates the Session Identifier securely. No packet sniffing! Only the client and server know.
Re: Secure pages with less encryption and better performance..?
Hmm.. ok.. a few more questions..
1. What are you really gaining over putting the whole site under SSL? You claimed bandwidth on the last page.. is the bandwidth you save on the unencrypted HTML pages more than the bandwidth you use for the additional image request and response? What have you done to actually measure this? Likewise, how do you reduce the CPU usage for the additional request for every page load? Rather than running one script every page load now runs two with your system. That's not trivial on a high volume site.
2. If the image is being requested from a secure server isn't the user's browser going to fire a "This page contains secure and non-secure items." warning on every page load in IE6?
3. Is additional security on top of SSL really necessary? If you're using a 128bit certificate surely the effective risk is zero..
4. What happens if IE and/or Firefox changes the behaviour of their browser (likely in a FF beta) so that images in hidden divs aren't requested? Will the page continue to function giving a false sense of security, or will the user be warned?
1. What are you really gaining over putting the whole site under SSL? You claimed bandwidth on the last page.. is the bandwidth you save on the unencrypted HTML pages more than the bandwidth you use for the additional image request and response? What have you done to actually measure this? Likewise, how do you reduce the CPU usage for the additional request for every page load? Rather than running one script every page load now runs two with your system. That's not trivial on a high volume site.
2. If the image is being requested from a secure server isn't the user's browser going to fire a "This page contains secure and non-secure items." warning on every page load in IE6?
3. Is additional security on top of SSL really necessary? If you're using a 128bit certificate surely the effective risk is zero..
4. What happens if IE and/or Firefox changes the behaviour of their browser (likely in a FF beta) so that images in hidden divs aren't requested? Will the page continue to function giving a false sense of security, or will the user be warned?
Re: Secure pages with less encryption and better performance..?
<<1.>>onion2k wrote:Hmm.. ok.. a few more questions..
1. What are you really gaining over putting the whole site under SSL? You claimed bandwidth on the last page.. is the bandwidth you save on the unencrypted HTML pages more than the bandwidth you use for the additional image request and response? What have you done to actually measure this? Likewise, how do you reduce the CPU usage for the additional request for every page load? Rather than running one script every page load now runs two with your system. That's not trivial on a high volume site.
2. If the image is being requested from a secure server isn't the user's browser going to fire a "This page contains secure and non-secure items." warning on every page load in IE6?
3. Is additional security on top of SSL really necessary? If you're using a 128bit certificate surely the effective risk is zero..
4. What happens if IE and/or Firefox changes the behaviour of their browser (likely in a FF beta) so that images in hidden divs aren't requested? Will the page continue to function giving a false sense of security, or will the user be warned?
I added bandwidth, the more obvious reason is CPU. Fact, SSL requires more CPU. Period. I did figure SSL required more bandwidth, which it does, just not as significant as I thought (if you read Apollo and I's discussion). The idea is better performance. Running SSL for all request PHP, HTML, IMG, JS, ZIP, CSS, etc., etc. is much more significant than 1 SSL request. I believe I clocked it at .0001 seconds (for me).
<<3.>>
Not sure what additional security you're talking about..?
<<4.>>
I doubt that. Anyhow, exclude the div tags, if it makes you feel better.
<<2.>>
With ALL this discussion, I grant you this. Would be a huge annoyance. Enough for me not to use this method myself. Give yourself a pat on the back.
Well, the result of this method is that it can possibly present an annoying message. = bad
Re: Secure pages with less encryption and better performance..?
onion2k,
I have solved your #2 issue by adding a third request. I have created a second post to allow less reading and hopefully an easier understanding:
viewtopic.php?f=34&t=82587
Please respond there.
I have solved your #2 issue by adding a third request. I have created a second post to allow less reading and hopefully an easier understanding:
viewtopic.php?f=34&t=82587
Please respond there.