Prevent Session Hijacking with HTTP and a little HTTPS
Moderator: General Moderators
-
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
It is true, what onion2k said. I would be able to jump from one page to another without regenerating OR just click stop before it ends the redirect.
SSL is slow, compared to normal HTTP connections, especially on overloaded servers, like eBay and such and such. It's the price of safety...
Your method, requiring the opening of three pages, getting their information and process it... It might be even slower to regenerate, and the user might not be there to wait for that.
I believe the best way would be to have all your images, javascript and stylesheets on a different domain or subdomain and then include them using full URLs to identify http://. This would show the secure/unsecure warning in IE, but it's fast, and you only use the SSL for the data, which is what is supposed to be secured. You also don't leak session data, because the session is on a different domain than the images, javascripts and stylesheets.
SSL is slow, compared to normal HTTP connections, especially on overloaded servers, like eBay and such and such. It's the price of safety...
Your method, requiring the opening of three pages, getting their information and process it... It might be even slower to regenerate, and the user might not be there to wait for that.
I believe the best way would be to have all your images, javascript and stylesheets on a different domain or subdomain and then include them using full URLs to identify http://. This would show the secure/unsecure warning in IE, but it's fast, and you only use the SSL for the data, which is what is supposed to be secured. You also don't leak session data, because the session is on a different domain than the images, javascripts and stylesheets.
Re: Prevent Session Hijacking with HTTP and a little HTTPS
That's a pretty significant problem though really. Any security warning showing in the browser will mean 100% of your users will go elsewhere.Bruno De Barros wrote:This would show the secure/unsecure warning in IE, but it's fast, and you only use the SSL for the data, which is what is supposed to be secured.
-
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
Damn why does IE show that error?
Nevertheless, I'd say they are used to that. For example, Yahoo does that. But it's still bad.
Nevertheless, I'd say they are used to that. For example, Yahoo does that. But it's still bad.
Re: Prevent Session Hijacking with HTTP and a little HTTPS
All browsers show the error. For example, in Firefox if you have a mix of secure and non-secure the address bar will be red rather than green. It's just that IE6 is the only one that uses an alert. Frankly, I think IE6's way is the best. It makes it very obvious the page might not be as secure as it appears.
Re: Prevent Session Hijacking with HTTP and a little HTTPS
I thought about that as well, but would rather go all HTTP or HTTPS being that 55% (rough figure) of internet users use IE.Bruno De Barros wrote:Your method, requiring the opening of three pages, getting their information and process it... It might be even slower to regenerate, and the user might not be there to wait for that.
I believe the best way would be to have all your images, javascript and stylesheets on a different domain or subdomain and then include them using full URLs to identify http://. This would show the secure/unsecure warning in IE, but it's fast, and you only use the SSL for the data, which is what is supposed to be secured. You also don't leak session data, because the session is on a different domain than the images, javascripts and stylesheets.
Actually, I'm having second thoughts about my methods as well. I'm okay with a page failing the secure request, but I'm wonder just how much performance I really gain. I am making 3 no cache page request, one being HTTPS.
I think I'm going to run my anonymous pages HTTP and my authenticated pages HTTPS with a sub domain (e.g. https://members.mywebsite.com/account.php).
Re: Prevent Session Hijacking with HTTP and a little HTTPS
In some MITM scenarios (commonly, proxies) one could also actively modify http requests and responses. A simple change of resource URL would cause the client to leak the SID to the proxy.
It's a fail, go over it. That's what https is intended for.
It's a fail, go over it. That's what https is intended for.
Re: Prevent Session Hijacking with HTTP and a little HTTPS
Mordred,Mordred wrote:In some MITM scenarios (commonly, proxies) one could also actively modify http requests and responses. A simple change of resource URL would cause the client to leak the SID to the proxy.
It's a fail, go over it. That's what https is intended for.
I was never intending to out-do https, only http.. Anyway, I have already waved the white flag. But, you might want to go to shiflett.org and give them the heads up..
Edit:
Tell them at shiflett.org "It's a fail, go over it." because of what you're suggesting. Go!!
Last edited by vspin on Thu May 15, 2008 6:23 am, edited 1 time in total.
Re: Prevent Session Hijacking with HTTP and a little HTTPS
Chris is a member of this forum, I expect he'll read this eventually.vspin wrote:I was never intending to out-do https, only http.. Anyway, I have already waved the white flag. But, you might want to go to shiflett.org and give them the heads up..
Re: Prevent Session Hijacking with HTTP and a little HTTPS
Yes, I know and Mordred is his biggest fan. I'd love to see him make the comments he has made to me.onion2k wrote:Chris is a member of this forum, I expect he'll read this eventually.vspin wrote:I was never intending to out-do https, only http.. Anyway, I have already waved the white flag. But, you might want to go to shiflett.org and give them the heads up..
I like shiflett.org methods, don't get me wrong, but Mordred remarks contradicts what he believes is not a failure.
Re: Prevent Session Hijacking with HTTP and a little HTTPS
vspin, I'm afraid I didn't understand what you mean, especially I fail to make the connection with shiflett.org
Maybe you are referencing some article there which is relevant to the discussion here? Do post an URL if so.
It's good to admit your mistakes, so I'm glad you wave the white flag on your method. What I'm not happy with is your hostility here - while I attacked your method (which is the best kind of service one would expect in a security forum - a volunteer one at that - and that's what people generally come here for), you on the other hand seem to attack me personally (at least it seems so, because I can't fully understand what you mean). I'll be glad to hear what you have to say about my arguments, but do keep in mind that ad hominem has not been a valid argument since a while.
Maybe you are referencing some article there which is relevant to the discussion here? Do post an URL if so.
It's good to admit your mistakes, so I'm glad you wave the white flag on your method. What I'm not happy with is your hostility here - while I attacked your method (which is the best kind of service one would expect in a security forum - a volunteer one at that - and that's what people generally come here for), you on the other hand seem to attack me personally (at least it seems so, because I can't fully understand what you mean). I'll be glad to hear what you have to say about my arguments, but do keep in mind that ad hominem has not been a valid argument since a while.
Re: Prevent Session Hijacking with HTTP and a little HTTPS
The same comment (in your opinion) "It's a fail, go over it." you made about my method can be said about yours. Since you're always posting links to shiflett.org, I assumed this is where you are learning your methods. Forgive me if I'm wrong.Mordred wrote:The most common way of hijacking a session is through XSS with cookie-stealing javascript. Your options:..
..2. IP/User agent locking of the session (not 100% guaranteed to work)..
..In some MITM scenarios (commonly, proxies) one could also actively modify http requests and responses. A simple change of resource URL would cause the client to leak the SID to the proxy.
It's a fail, go over it. That's what https is intended for.
<<It's good to admit your mistakes, so I'm glad you wave the white flag on your method.>>
No mistake made. I'm waving the white flag because I think that there may be little performance gain. Not because my method does not supply adequate protection in contrast to HTTP methods. My method may not be desirable, but it's not failure (based on HTTP standards).
<<What I'm not happy with is your hostility here>>
Cheer up.
<<while I attacked your method (which is the best kind of service one would expect in a security forum - a volunteer one at that - and that's what people generally come here for)>>
Yes, you attacked, but supplied no information other than saying it's a failure, which is much too vague of a response. onion2k comments on the other hand, were very constructive. He ran scenarios and found faults.
<<you on the other hand seem to attack me personally (at least it seems so, because I can't fully understand what you mean)>>
Trust me, I'm not attacking you at a personal level. What do you say we chalk this up as misunderstanding between us?
-
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
Does it? Oh heck... Forget it. Whenever I need to protect data, I'll just SSL everything.onion2k wrote:All browsers show the error. For example, in Firefox if you have a mix of secure and non-secure the address bar will be red rather than green. It's just that IE6 is the only one that uses an alert. Frankly, I think IE6's way is the best. It makes it very obvious the page might not be as secure as it appears.