Suppose you have a website where people can post artwork. Artists who post their artwork on the site can also post their bitcoin address, so that people can send a donation to an artist if they like the artist's work. Users can also post comments about other users' artwork.
Now, suppose there is a piece of artwork that is really popular. The page on the site where this particular piece of artwork is hosted gets thousands of page views per day, and a fair number of people make donations to the artist by sending bitcoin to the artist's bitcoin address.
An attacker sees that the site is designed such that the author's bitcoin address is contained in a <div>
element on the page, like so:
<div id=divbitcoinaddress>12mEaXDMYPTFTMkuraoTMk8zVEFrPvve7W</div>
where 12mEaXDMYPTFTMkuraoTMk8zVEFrPvve7W
is the author's bitcoin address.
So, the attacker posts a comment that contains:
<script>divbitcoinaddress.innerText='1Jhr6tVXvEsdz6WKpbrG5BkD45BuNXWZB9';</script>
where 1Jhr6tVXvEsdz6WKpbrG5BkD45BuNXWZB9
is the attacker's bitcoin address.
The comment is stored in the site's database, along with all of the other comments. When a user surfs to the page, and the page loads, the server serves the page, including the comment, as it should. Then, the user's browser runs the scripting in the <script>
tag, and now the author's bitcoin address has been replaced with the attacker's.
Same Origin Policy (SOP) will not stop this attack, because there is no cross-origin activity here. The malicious code was served from the same origin as the rest of the site.
However, Content Security Policy (CSP) could have prevented this attack. If the site has a strict CSP that prohibits inline scripting, then this would prevent the malicious script from running.