Timeline for Should we force user to HTTPS on website?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 6, 2012 at 7:52 | comment | added | rook | @tylerl THat is a good question that probably deserves its own post. Really a redirect is just addressing a symptom of a problem. Having a redirect is a good thing, but you need to address mixed content vulnerabilities that would cause this to happen in the first place. Also set the "secure" flag on session id's. Also warn IE users that they are potentially vulnerable to attack. | |
| Nov 6, 2012 at 5:22 | comment | added | tylerl | No argument that non-ssl traffic is exploitable. My question is this: If you don't return a redirect when traffic arrives on port 80, what do you return? Is there anything you can do that would not be exploitable? Assuming a browser that doesn't support STS gets sent by a third-party to your site over HTTP. If you don't return a 302, what do you return which would be safe? | |
| Nov 6, 2012 at 4:59 | comment | added | rook | @tylerl Depends who you ask: w3schools.com/browsers/browsers_stats.asp . Personally I don't know anyone that uses IE. And you could not be more wrong about the redirect, the attacker can send whatever response they would like in a MITM attack, and SSLStrip will remove the https redirect for you. I am actually surprised i am even debating this, i thought this was obvious. | |
| Nov 6, 2012 at 4:24 | comment | added | tylerl | chrome = 30%, ff v4+ = 20%; so neither majority nor minority. Again, the redirect is not exploitable, but the request BEFORE the redirect can be sniffed/spoofed. The catch is that if you didn't solicit the request, there's nothing you can do about it. Whether you send a redirect, a 404, a 500, or no response at all, the attacker can STILL sniff/spoof the connection. There's no vulnerability in the redirect itself. It's like saying a bank is insecure because you can get robbed on drive over to it. | |
| Nov 6, 2012 at 3:41 | history | edited | rook | CC BY-SA 3.0 |
added 26 characters in body
|
| Nov 6, 2012 at 3:13 | comment | added | rook | @tylerl Throwing a 302 redirect over http to an https connection is trivial to exploit. If you don't see how this is serious problem, fire up wireshark and look at the traffic. HSTS is supported by chrome and firefox, which is the STRONG MAJORITY of browsers. IE has never been known for security, so i wouldn't be surprised if they just ignored this feature. | |
| Nov 6, 2012 at 0:58 | comment | added | tylerl | STS is only supported by a minority of browsers. The redirect mechanism isn't itself exploitable, but it would be insecure to submit information through an encrypted connection even if later redirected, but that's not something that the server can prevent without blocking port 80, since no server action can be taken at all until after the request has been submitted. | |
| Nov 5, 2012 at 19:39 | history | edited | Rory McCune | CC BY-SA 3.0 |
typo
|
| Nov 5, 2012 at 16:55 | history | answered | rook | CC BY-SA 3.0 |