• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Content Security Policy (CSP)

rugk

Active member
#1
As XenForo was built with "security in mind" I assume you want to secure or make it possible for server admins to secure their website. A great way to do this is Content Security Policy. However XenForo has some issues which make it difficult to use this in a strong way.

Basic facts
All test were executed with XenForo 1.4 on Apache. Javascript test were executed in Firefox 38.0.5.

What is Content Security Policy?
Content Security Policy can be accomplished with a simple HTTP header send by the webserver. It's basically a bunch of rules for the webbrowser, which prevent XSS attacks. And that XenForo is immune to XSS attacks is of course not the case as we can see at the latest update. And no I don't want to blame anyone - this can happen and happens in every forum software at a particular time. The point is that the CSP header can effectively prevent such attacks.

More information:

What is the problem?

The problem is that XenForo uses at some points Javascript code in a way, which should be disallowed by a CSP to make the protection as effective as possible.
I hope the details explain this more clearly.
  1. Get rid of inline scripts & styles
    The first - quite big - problem is that XenForo uses at various points JS embedded into HTML code. This may be easy for developing, but because of this I have to adjust the CSP (add 'unsafe-inline') and with this modification it won't prevent the biggest threat of XSS - inline script injection.
    As you maybe have to change many parts of XenForo this may not be easy to do, but maybe it's an idea for XenForo v2. :)
    As Mike West writes in the already linked HTML5Rocks blog:
    Banning inline script is the biggest security win CSP provides, and banning inline style likewise hardens your application. It’s a little bit of effort up front to ensure that things work correctly after moving all the code out-of-line, but that’s a tradeoff that’s well worth making.
    As for inline-styles (CSS) I did not find any one used in XenForo actually. And that's great! :)
  2. Get rid of eval
    Eval is evil. This is widely known and therefore it is (like inline-scripts) by default disallowed with CSP.
    But in XenForo I only found 2 files which are using eval:
    1. The jQuery file under /js/jquery/jquery-1.11.0.min.js uses eval in line 2. Here you maybe just have to use another jQuery (version) or something like this.
      For the user this jQuery file (and it's eval part) seems to be only used if you view the recent activity on a users profile page.
    2. And also one javascript for the flash uploader uses eval: /js/swfupload/swfupload.min.js :(
If this is solved then we would have the possibility to use a robust CSP header, which disallows inline-javascript and eval, so that XSS attacks can be defended.

Other things
Another block is quite interesting. We currently use a CSP header which does not allow 'self' for font-src as we did not saw any fonts loaded from anywhere on the forum. Currently we use the default XenForo style.
However we sometimes see reports from some fonts which were tried to be loaded.
E.g. on our start page some browsers tried to load /fonts/KievitWebPro-Light.woff. This is especially interesting as the dir 'fonts' doesn't exists at all in XenForo.
We could not reproduce this report.
Does somebody has an idea why/where/at which action this font is loaded?
 
Last edited:

Mike

XenForo developer
Staff member
#2
The font issue is probably related to a user browser add-on. Those often modify the DOM to change behaviors.
 

rugk

Active member
#3
The font issue is probably related to a user browser add-on. Those often modify the DOM to change behaviors.
Yes this could of course be and I at first assumed the same. However it is not that likely, because at first the "source-file" is not something like extension://, but our normal homepage address. Secondly it's always the same font on the same URL, so if it would really be an add-on it have to be the same add-on and thirdly: Why would an add-on load a font from our homepage? I would understand it if the font came from http://fonthoster.myfantasticaddon.com or any local resource, but from our own site?
 

Mike

XenForo developer
Staff member
#4
If it's modifying the DOM, then it may appear to actually be from the source. I have seen that happen before. I've actually seen things like this show up in the DOM explorer.

However, if you're able to determine this, you presumably can reproduce it, so you should be able to search the source and dive into the reference to find where it's coming from. You may also want to confirm with all browser extensions disabled (and/or confirm it with another browser).
 

rugk

Active member
#5
Well, it's exactly the problem that I cannot reproduce it. Why I can determinate it has another reason.
What I did not described in detail was that CSP has another nice feature: With an report-uri in the header you can get reports from browsers where the CSP is violated. This way you can even detect XSS attacks - or such stupid errors, which seems to occur. But because of this I don't even know which browser they used (okay it have to be a browser, which supports CSP and the reporting feature, but nothing more).
This is why I said I can't reproduce it - I only know that it appears.
 

Mouth

Well-known member
#10
What is Content Security Policy?
Content Security Policy can be accomplished with a simple HTTP header send by the webserver. It's basically a bunch of rules for the webbrowser, which prevent XSS attacks.
This would be a great addition to XF security, and a good selling point.
 

sheel

Active member
#18
If someone plans to block inline styles from the own domain, don't.
XF2 uses them too.

I have an addon with some CSP options as well as custom string configuration, but because of some reasons, I can release it not before november :/ If someone still needs it then, I'll be glad about downloads :D