While ownCloud uses CSP since version 5.0.0, which was released in March 2013 and was thus one of the first larger deployed open-source projects using it, a lot of persons have yet not really heard of the implications and advantages of the CSP. Hopefully this post can help to shed some light on it.
It shall be noted that this post is not meant as a complete web application security primer and intentionally neglects some other very important security aspects to make the subject easier to understand.
#A very short introduction to XSS A crucial part of being able to understand CSP is to have a rough understanding of the security risks that it is able to prevent. Let’s thus shortly talk about one of the most common web application security issues: Cross-Site-Scripting (XSS).
When you develop a web application you usually very often take user input, do some stuff with it and return a response to the user. For example the following PHP script will ask the users for their name and display it back to the user:
If you are a security aware developer you might have already spotted the security problem: The user input is not sanitized before displaying it back to the user and thus this is vulnerable to so called Cross-Site-Scripting.
No worries if you still didn’t get it. Let’s just consider what would happen if a user would provide something like
<script>alert(1)</script> to the input box. The output would now look like the following:
Developers can prevent this by encoding all user output appropriately, so that for example a
< would get inserted
< in the HTML. However, developers are humans too and humans are unfortunately very error prone. Especially
errors like this can happen very quickly.
#How the Content-Security-Policy can help The Content-Security-Policy, or short CSP, is an open standard implemented by most browser vendors (i.e. everything except Internet Explorer) that allows websites to define additional security policies that are aimed to prevent attack vectors such as Cross-Site-Scripting.
When you accessing an ownCloud instance the browser will receive a
Content-Security-Policy header with a
get ignored by browsers.
#Ongoing improvements When it comes to security the best option is a secure by default model. This is also in what we at ownCloud believe and a reason behind many of the recent security optimizations that we have done recently.
This however also means that with 8.1 it is not possible anymore to define a default policy in
config.php using the
custom_csp_policy configuration switch. We believe that there is not a lot of sense in maintaining yet another
switch which was only introduced as a workaround.
While this sounds not too scary let’s think about it one moment. What would happen if an attacker inserts a faked login form? How many users would realize that it is actually a malicious form?
If you are interested in these topics I can only highly recommend you to take a look at Postcards from the post-XSS world.