The Content-Security-Policy is used to protect applications against content injections such as XSS and HTML injections. It is a widely adopted and crucial security standard. Very often, XSS vulnerabilities become useless because of the CSP.
This post will demonstrate that content injections can still be exploited regardless of having a Content-Security-Policy in place.
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 lethal attacks.
Sometimes, even if the Content-Security-Policy is configured as suggested by the recommendations and reference manuals, the application can still be exploited with content injections.
At the end of this post, a form-action Content-Security-Policy will be exposed. This bypass allows attackers to exfiltrate information from users' accounts despite of facing an adequately configured Content-Security-Policy. This attack doesn't rely on misconfigurations and works in a lot of scenarios.
Browsers' security defenses against dangling markup attacks were bypassed too: Dangling markup attacks were very 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 defenses, resurrecting dangling markup attacks back from the dead. With one of these bypasses it is possible to exploit content injection vulnerabilities even when facing the strictest CSP configurations (e.g. everything set to 'none': default-src 'none'; form-action: 'none').
Another one of these bypasses is a UTF-16 character encoding attack useful for bypassing browsers' security validations.
Possibly this post will help transform those worthless code injection bugs into exploitable vulnerabilities.
(more…)