Content Security Policy

[RSteinwand]

This is going to create a lot of work for me. http://www.w3.org/TR/CSP/

To reap the greatest benefit, authors will need to move all inline script and style out-of-line, for example into external scripts, because the user agent cannot determine whether an inline script was injected by an attacker.

This is a no-no (inline css) and the style elements need to be removed:

Code: Select all

<div class="no-print" style="float:right;padding:4px 15px"><a href="#" onclick="window.print();return false;" style="text-decoration:none">

[Albert Wiersch]

Interesting. I am not that familiar with that recommendation, but why do you need to implement it? Do you think your site is vulnerable to script injecting by attackers?

[RSteinwand]

Hi Albert,

Yes, it was news to me too, but I started implementing the easy ones that are controlled by a template.

More here: https://developers.google.com/speed/doc ... SSDelivery

For PCI (Payment Card Industry) and security reasons, we are always wary of XSS. In this case primarily for performance, but also because it'll eventually be a requirement for us. Some audit would find it and I'd have to fix it like everything else. PCI= audit required to process credit cards.

[RSteinwand]

To take advantage of CSP, a web application opts into using CSP by supplying a Content-Security-Policy HTTP header.

I’m pretty sure that will show up in one of our audits before long, since it’s already live in FF and Chrome.

More: http://en.wikipedia.org/wiki/Content_Security_Policy

Google Chrome supports this as of version 25. Firefox support this as of version 23, released on 6 August 2013.

If the Content-Security-Policy header is present in the server response, a compliant client enforces the declarative whitelist policy. One example goal of a policy is a more strict execution mode for JavaScript in order to prevent certain cross-site scripting attacks. In practice this means that a number of features are disabled by default:

• inline JavaScript (e.g. <script></script>, DOM event attributes like onclick, and anchor tags with an href value that starts with "javascript:") are blocked - all script code must reside in separate files, served from a whitelisted domain (can be enabled by unsafe-inline),

• dynamic code evaluation (via eval() and string arguments for both setTimeout and setInterval) are blocked (can be enabled by unsafe-eval)

[Albert Wiersch]

Thanks Rick... it looks like this is another standard that CSE HTML Validator might be able to help with... now to only find the time to look into it.

I'm currently busy improving HTML5 support.

[RSteinwand]

No need to rush for me. I'm only going to implement the easy style changes for now and ease into it. You might want to recognize the header syntax, but anything else will be work.

If I turned it on now, I'd be stuck with a generic site that only has links and no chance (that I know of) for Ajax or script animation and everything (!) would be broken. I use "onclick" a LOT.

Since a site will be severely limited by enabling this, I'm not sure how popular it would be. I suppose you could do this if you have a dynamic site and can move a lot of the functionality to the server side using PHP or a similar technology. We could do it, but a what cost?

[Albert Wiersch]

I haven't looked much into this yet, but It does sound like it will greatly reduce functionality... but I can see how some "high-security" sites (like financial sites) would want to forfeit the functionality for more security.

As for CSE HTML Validator, I'm thinking that it could help warn users when features are used that won't work due to the security, not just check the syntax of the header.

[Lou]

That sounds like a helpful approach Albert.

[MikeGale]

Haven't formed an opinion of this yet.

Time will tell what the uptake is...

I think checking for this sort of thing would be really useful to have.

[Albert Wiersch]

Is anyone here besides RSteinwand making use of Content Security Policy?

And if you are using it, what parts of it are you using? I am considering looking into adding at least some support for this... if there is some demand for it and it's not too time consuming to implement.

[RSteinwand]

I'm still just eliminating most of my inline styles. I doubt I'll ever be able to do the scripts. Every page of mine has scripts on bottom of the page of some sort. Finally got rid of 99% of my doc.writes. Just one nasty page left that's full of them.

[ryanjoness]

I’m pretty sure that will show up in one of our audits before long, since it’s already live in FF and Chrome.

[Albert Wiersch]

Hi Rick and others,

How has your experience been with CSP and are you still using it?

I've added improved support for it in an upcoming update of CSE HTML Validator. That is, it will perform some checks on a serialized CSP policy when sent via HTTP header or in a meta tag.

I'm thinking about possibly further enhancing the support for CSP to generate error or warning messages if inline and embedded styles or scripts have been used when they have been disallowed by a CSP policy. If you have any thoughts on this then please respond here. Thanks!

[RSteinwand]

Hi Albert,

So far no mention of it in audits. Meanwhile on the public side, I'm inlining critical css at the top of every page and postloading an external css at the bottom. If anything I've moved away from the recommendation. But there's a big difference between the public and secure side.

[Albert Wiersch]

Hi Rick,

Thanks for the info! However, it wasn't clear to me if you use CSP at all (even just a little) or if you've completely moved away from it and don't use it at all? I pulled up your business website and didn't see it used at all.

It doesn't look like CSP is used that much but I haven't looked into its usage that deeply yet. However, it seems that the most popular browsers do have support for it.