Prevent auto clicked link XSS attack using CSP

Question

Whilst using CSP for a slightly different purpose (sandboxing) I realized that a very simple auto clicked link seems to bypass even relatively strict CSP. What I am describing i

Answer 1

CSP is one of the ways to reduce the damage done by XSS, but it is by no means a magic wand that fixes all issues caused by XSS vulnerabilities. This non-goal is also listed explicitly in the CSP specification:

Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks. As a first line of defense against content injection, server operators should validate their input and encode their output.

If you have to run JavaScript code, but you cannot trust the code, then you could serve the page with a sandbox directive without the allow-same-origin flag. With this CSP directive, the page will run at a unique security origin, which does not share any state (i.e. cookies, DOM Storage, databases, ...) with the displayed origin. Consequently, injected scripts cannot leak information, because they cannot get the information in the first place.

For example, to allow inline scripts to run, but without access to same-origin data, use:

default-src 'none'; script-src 'unsafe-inline'; sandbox allow-scripts

Don't bother with blacklisting JavaScript methods as suggested by another answer, because 1) you will always overlook a method and 2) disabling JavaScript APIs may break your web application in unexpected ways, and 3) the attacker only needs one hole to do damage, and your (custom) application probably contains at least one method which can be abused by an attacker.

Answer 2

This is unlikely going to be a satisfying approach - and obviously it isn't based on CSP - but it might be your only option if you really have to prevent such attacks. Before using anything like this, make sure that there is really no way to disable inline scripts (which should cover most attacks). Moreover, you should send your feedback to the public-webappsec@w3.org mailing list with a [CSP2] subject.

Here my (incomplete) idea:

function guardMethods(clazz, methodNames, urlGetter, allowFilter, reportViolation) {
    var prototype = clazz.prototype;
    methodNames.forEach(function (methodName) {
        var originalMethod = prototype[methodName];
        if (originalMethod) {
            Object.defineProperty(prototype, methodName, {
                value: function () {
                    var url = urlGetter.apply(this, arguments) || '';
                    if (allowFilter(url)) {
                        return originalMethod.apply(this, arguments);
                    } else {
                        reportViolation(url);
                    }
                }
            });
        }
    })      
}

function allowFilter(url) {
    // todo: implement
}

function reportViolation(url) {
    console.error('Redirection prevented:', url);
}

guardMethods(HTMLAnchorElement, ['click', 'dispatchEvent', 'fireEvent'], function () {return this.href}, allowFilter, reportViolation);

You would have to implement similar guards for location, location.href, window.open and other functions/properties/events which allow to redirect to other pages. If you miss just one, then you are still vulnerable. Forms, XHR and most other resources can be covered with CSP itself. As far as I know, the prototype hack does not work in some older browsers.

Once more, I do not recommend to use this. The chance that you make a mistake or that it does not work in some browsers or that a new API will be added which can be leveraged for redirects is just too high.

Answer 3

Content Security Policy is for the security of the page itself. Navigating to another page is not a bypass or something that concerns CSP. CSP is only concerned with your page and what it can do. It's also not about restricting the utility of the browser for the end user (like the ability to install plugins or open links).

---

default-src 'none';

This tightens the policy to allow no XHR / Fetch / WebSockets / CSS / Font / JavaScript / Plugin content from anywhere. These all have their respective properties but in their absence the default property is used. You have not attempted to do any of these in your javascript.

script-src 'unsafe-inline';

This relaxes the policy to allow any javascript that is embedded into the page to be used. This includes onclick/onhover and that whole family of unsafe attributes. To quote the spec:

In either case, authors SHOULD NOT include either 'unsafe-inline' or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.

Instead of this, if you feel the need to embed content in the document itself for whatever reason, there are hash and nonce values that can be placed in your policy string to whitelist your inline scripts.