CSP style-src: 'unsafe-inline' - is it worth it?

Question

Currently I'm using Modernizr on all my sites and it turns out because of how it works it requires unsafe-inline styles to be allowed. I am already not allowing inline scripts and unsafe-eval for scripts. Curious as to what security risks there are for allowing inline styles?

Ulrikaumeko

Answer 1

Allowing inline styles makes you susceptible to a the "other XSS". Cross Site Styling attacks.

The idea here is that any places where a user can inject a style attribute into your document they can modify the appearance of your page any way they want. I'll list a couple potential attacks ordered by increasing severity:

1. They could turn your page pink, and make it look silly.
2. They could modify the text of your page, making it look like you're saying something offensive that could offend your readership audience.
3. They could make user generated content, like a link they provided appear outside of the normal places where people expect to see user content, making it appear official. (eg, replacing a "Login" button on your site with their own link).
4. Using a carefully crafted style rules they could send any information included on the page to external domains and expose or otherwise use that data maliciously against your users.

The fourth example, with the information being leaked to external domains could be entirely prevented in spite of the unsafe-inline provided you ensure your other CSP rules never allow any kind of request to go to a untrusted or wildcard domain. But the first 3 will always be possible if you miss blocking a style attribute somewhere.

Mike West did a good talk on this for CSSConf a few years back for some more examples.

Krasnoff

Hey nice post, i'm curious though, what if it's a mobile app(downloaded)? would this be considered a threat? i'd assume they would only be able to mess with their own app in that case and make some odd css things to their own app, or? – Asphyxiant

Would this be a webview style app? It would be same attack vector as on normal browser delivered content. Its not the user that is attacking themselves but rather an external (hence "Cross-Site") entity changing the experience you intended for them. This can be hijacked third party JS/CSS (are you verifying everything you package?), improperly sanitized content or various other vectors like images that I'm not yet smart enough to properly understand. – Jodhpur

It seems with wordpress sites most themes are not coded to be compliant with a CSP hence you end up having to use unsafe-inline, unsafe-eval and even data: otherwise your entire site breaks and looks horrible. While I understand that using unsafe-inline and unsafe-eval can open you up to XSS attacks would "X-XSS-Protection 1; mode=block" not already help prevent that? It seem wordpress theme and plugin authors have a lot to do make their stuff CSP compliant. – Trinidad

X-XSS-Protection is good, but it's not perfect. It'll automatically protect you from 70-80% of the XSS exploits you might casually encounter in production. You might compare it to anti-virus from the consumer security world, with a blacklist of bad bevaiour. CSP is a more aggressive solution guaranteeing 100% protection (if browsers work correctly).The consumer security parallel would be sandboxing applications, they can do whatever they want, but they can't affect things outside their play area. A determined attacker can work around X-XSS-Protection, but not CSP. – Krasnoff

Couldn't they just as easily mess up your page by modifying classes? I'm still not seeing the benefit. – Indoors

Whois "they", how do they have access to your page? Is the code running as a virus of the clients computer? Are they browser dev tools, and modifying the page? – Deathlike

For anyone that will arrive at this page looking for CSP information, X-XSS-Protection is considered outdated, Firefox never implemented it, and Chrome dropped its support. – Aiguillette

@Aiguillette Note that X-XSS-Protection still provides some protection for older browsers — such as Internet Explorer — that do not support CSP. However, these protections should only be considered a weak defense against cross-site scripting attacks. observatory.mozilla.org/faq TL;DR - X-XSS-Protection should still be used, it can only help. – Suzannasuzanne

@Suzannasuzanne According to OWASP, the X-XSS-Protection header can even introduce additional security issues on the client side. "As such, it is recommended to set the header as X-XSS-Protection: 0 in order to disable the XSS Auditor, and not allow it to take the default behavior of the browser handling the response." Use CSP instead. Source: owasp.org/www-project-secure-headers/#x-xss-protection – Sacci

Answer 2

I agree with Jacob - please observe the following pattern (from MantisBT):

/**
 * Print user font preference
 * @return void
 */
function layout_user_font_preference() {
    $t_font_family = config_get( 'font_family', null, null, ALL_PROJECTS );
    echo '<style>', "\n";
    echo  '* { font-family: "' . $t_font_family . '"; } ', "\n";
    echo  'h1, h2, h3, h4, h5 { font-family: "' . $t_font_family . '"; } ', "\n";
    echo '</style>', "\n";
}

Will you create a temporary .css file for each user, just to provide script kiddies with audit tools a way to make a dollar ?

If you don't code - you won't make any error ! Going towards 0 bytes content with these absurdities ...

And if my user love his page pink or rainbow, then let the guy have it :)

Louislouisa

Answer 3

Personally I find not using unsafe-inline for CSS is impractical. It means I have to use an external style sheet file for EVERY style. Coloring text, centering text etc. It can be done. You can do this by using a main style sheet "main.css" and a file sheet for every page ("index.css", "contect.css", etc). However I am not so stupid that I allow arbitrary code execution; I filter out all less then and grater then signs. I find this to be an unreasonable restriction. Blocking inline JavaScript is not as bad as blocking inline CSS. I can see blocking inline JavaScript. However I don't think I will do that ether. If you are careful to filter your less then and grater then signs (there are some other stupid things you can do besides not filtering these) if you don't make stupid mistakes that allows arbitrary code execution then you are safe. These inline blocks are only created to protect web developers that screw up there code in a way that allows arbitrary code execution. But the blocks make it a bit harder to code. So it's a trade off.

TLDR IMHO not worth blocking inline CSS, worth blocking inline JavaScript but unnecessary. I will NOT consider blocking inline CSS, I am not going to block inline JavaScript but I might consider it.

Experience: I am a web designer that designs in code using HTML CSS JavaScript and PHP. I have my own website that I coded by hand. And I validate with the official w3 validator. I keep up with web design standards like HTML5.

Hobart

"You're safe if you don't make mistakes" does not sound like a good security policy to me... – Exocentric