Tuesday, January 10, 2012

Content Security Policy (CSP) is a technology, that at the time of writting this is still a working draft, which will allow a web page to limit where external content can be loaded from. It allows the web page to define which domains image files, CSS files, JavaScript files, etc. can be loaded from. Additionally, inline JavaScript and style is not allowed; all JavaScript and style must be externalized. This externalization of JavaScript and style is the one feature I am most excited about; more on this later.

CSP has been discussed by others indicating it is not a complete solution to the XSS/Content Injection problem. A couple of the better posts about this are Postcards from the post-XSS world by Michal Zalewki and HTML scriptless attacks by Gareth Hayes. Both of these posts discuss what can be done with XSS/Injection Attacks that don’t require JavaScript. Even the introduction of the CSP draft states that it is “not intended as a first line of defense against content injection vulnerabilities.” Morale of the story, CSP will definitely help, but developers still need to validate input and encode output.

So why am I a big fan of CSP, specifically with regards to having to externalize JavaScript? Doing this means that several of the complicated encoding scenarios go away. Knowing what type of encoding to perform becomes, in the majority of cases, simple again. You no longer have event attributes such as onclick which will HTML decode the value of the attribute before passing the data to the JavaScript interpreter. With JavaScript externalized you no longer have the “javascript:” protocol used in HREFs, which are HTML Attribute decoded prior to determining what protocol is in use, then because the javascript protocol is used the data is URL Decoded prior to being passed to the JavaScript Interpreter. Basically, with JavaScript and style externalized you don’t have nested contexts where the web page is passing data through several different parsers!

Given the lack of nested contexts in the rendered HTML doesn’t mean all the XSS/Content Injection issues go away. Data still needs to be correctly encoded for whatever context it is being written to (see the OWASP XSS Prevention Cheat Sheet). Additionally, when using JavaScript to manipulate the DOM – this still needs to be done correctly using safe APIs such as setting innerText instead of innerHtml; there are several other articles discussing this so I’ll leave it at that.

I also believe there will be issues with dynamically generated style sheets and JavaScript (e.g. the CSS and JavaScript being generated by templating technologies such as JSP so that dynamic data can be inserted). However, I still believe overall it becomes easier to choose the correct encoding and filtering techniques when writting data into these types of files.
CSP can limit the damage potential of XSS/Content Injection Attacks (some) and it requires cleaner HTML which makes writing pages that utilize the correct encoding easier. This cleaner HTML will hopefully lead to less XSS/Content Injection vulnerabilities.