Introducing the SecurityHeadersPolicy in Alfresco Share

[erikwinlof]

A few weeks back we added a new security filter to Alfresco Share. It is a regular Java Servlet filter that applies http response headers to incoming requests to Alfresco Share. The headers that are returned are defined in a config section called SecurityHeadersPolicy in alfresco-security-config.xml. We did this mainly to improve mitigation of clickjacking attacks but we also added 2 headers to tighten up the security in Internet Explorer after a tip from Jens Goldhammer at FME.



To read more about clickjacking please visit OWASP's page on the subject:

https://www.owasp.org/index.php/Clickjacking



Now let's take a look at the default config for Alfresco Enterprise 4.1.4 (and on Community on HEAD), as you can see 3 headers are added by default:

<config evaluator='string-compare' condition='SecurityHeadersPolicy'>

  <headers>

    <header>

      <name>X-Frame-Options</name>

      <value>SAMEORIGIN</value>

    </header>

    <header>

      <name>X-Content-Type-Options</name>

      <value>nosniff</value>

    </header>

    <header>

      <name>X-XSS-Protection</name>

      <value>1; mode=block</value>

    </header>

  </headers>

</config>

Lets take a look at what implications these headers will have on browsers...

X-Frame-Options

Adding this header to an http response will tell the browser if Share pages are allowed to be put inside iframes or not. In our default config we have set this to SAMEORIGIN which means that Share pages are only allowed to be '(i)framed' inside Share or other webapps that happen to live under the same domain. In other words it will i.e. be possible to include http://www.acme.com/share inside an iframe on http://www.acme.com/portal.



If you do not want this to be allowed you can override the config and set the header to return DENY instead, you can do that by placing the following config in your share-config-custom.xml file:

<config evaluator='string-compare' condition='SecurityHeadersPolicy'>

  <headers>

    <header>

      <name>X-Frame-Options</name>

      <value>DENY</value>

    </header>

  </headers>

</config>

If you instead want to open up the possibility to include Share inside iframes on any domain you can do this by using the following config instead. Note! This is not recommended since it will open up the possibility of Alfresco Share being a target of a clickjacking attack.

<config evaluator='string-compare' condition='SecurityHeadersPolicy'>

  <headers>

    <header>

      <name>X-Frame-Options</name>

      <enabled>false</enabled>

    </header>

  </headers>

</config>

Note! Since we are on the subject of iframes, feel free to read this blog post about improved mitigation of phishing attacks in Alfresco Share by the introduction of the new IFramePolicy. It will decide which urls that Alfresco Share will allow to be put inside an iframe in the Alfresco Share client.

X-Content-Type-Options

This is only valid for Internet Explorer. Older version of Internet Explorer (8 and below) will *help* developers by sniffing the content of a returned resource and then execute the content as the content type that IE thinks the resource has, instead of the content type the server returned. To stop IE from doing this we are returning nosniff in the header.

X-XSS-Protection

Yep IE trying to *help* again. Instead of trusting the developer to do a good job of mitigating XSS attacks IE just can't keep its fingers away from your code. If it finds some code that looks suspicious (XSS code) it will manipulate (a.k.a. 'sanitize' it) to become safe and then execute the sanitized code. So what's bad about that? Well IE's 'sanitization' logic can be used by an attacker to actually introduce an XSS flaw on your site. As a 'solution' to this IE introduced the X-XSS-Protection header.



By default Alfresco Share will return '1; mode=block' for this header, which means that if IE *thinks* it has found an XSS attack it will not execute the code (instead of sanitizing it and running it which is the default).



It is also possible to set it to '0' which means that IE shall not even try and inspect the code for XSS attacks.

Adding additional headers

Adding additional headers to the config is also supported. Lets take the Strict-Transport-Security header as an example, it is used to force your browser to only allow https and not http communication. It is not provided by default in Alfresco Share but can be added by placing the following code inside your share-config-custom.xml file:

<config evaluator='string-compare' condition='SecurityHeadersPolicy'>

  <headers>

    <header>

      <name>Strict-Transport-Security</name>

      <value>max-age=31536000</value>

    </header>

  </headers>

</config>

I hope you have enjoyed this blog post, if you have any questions please add a comment below!