We have been going through XSS vulnerability in the past two posts. I am going to end this series with one last post about Secure Headers. We will go through a few headers that we can implement.
Environment testing was done on two Windows 10 machines with Sitecore 8.1 update 3. Browsers use were Chrome (), Firefox (47.0.1), Microsoft Edge (25.10586.0.0 and Internet Explorer 11 (11.494.10586.0). Fresh installs on both, no config patches or customizations.
You can protect your self with headers without any need for code. Some of the headers which are recommended are:
HTTP Strict Transport Security (HSTS)
HSTS informs browsers that the communication should only happen in HTTPS and not in HTTP.
HTTP Public Key Pinning (HPKP)
HPKP informs browsers to associate a specific cryptographic public key with a specific web server to prevent Man-in-the-middle (MITM) attacks with forged certificates.
The X-Frame-Options header indicates if a browser should allow the render of a page in a frame, iframe or object. By implementing this header a site can avoid clickjacking attacks, by ensuring that the content is not embedded into other sites.
The X-XSS-Protection informs your browser to enable XSS filter in your browser. Not all browsers support this header.
The X-Content-Type-Options header prevents MIME type confusion attacks by enforcing MIME types on script and style elements.
The Content-Security-Policy header prevents XSS attacks by dictating what kind of resources can be loaded into the browser.
Bas Lijten has written a few blog posts to go over some of the above. Here are the links: Sitecore Security #3: Prevent XSS using Content Security Policy & Sitecore Security #2: Secure connections and how to force the browser to use the secure connection.
This header configures the built in reflective XSS protection found in some modern browsers. Valid settings are:
0 – disable the protection
1 – enable the protection. If the browser detects an attack, the browser will sanitize the page
1; mode=block – enable the protection & block the response. If the browser detects an attack, the page will not be loaded and the browser wont sanitize the page
1; report=http://[YOURDOMAIN]/your_report_URI – enable the protection. If the browser detects an attack, he browser will sanitize the page and report the violation
By default we do not get many headers from the base install of Sitecore.
Lets do some testing.
X-Xss-Protection “0” – Disable
Now we load http://local.testsc8.com/?special=%3Cscript%20src=%22https://somedomain.com/somescript.js%22%3E%3C/script%3E on a page which consumes the special query string parameter and renders it on the page causing the script to execute.
The header gets loaded as we expected but on closer look on all four browsers, each acts differently. Chrome and FF load the script where as Microsoft Edge and IE11 do not load the script. We also do not see any console output.
X-Xss-Protection “1” – Enable & Sanitize
Now we load http://local.testsc8.com/?special=%3Cscript%20src=%22https://somedomain.com/somescript.js%22%3E%3C/script%3E . Something very interesting happens:
- Chrome, Microsoft Edge and IE11 respect the header value of 1 and do not load the script.
- Chrome, Microsoft Edge and IE11 show a console message.
- Props to IE11 (never thought I would say this about IE), it even shows a very visible notification to the user.
- Firefox on the other hand still loads the scripts and completely ignores the header.
X-Xss-Protection “1; mode=block” – Enable & Block
- Now we load http://local.testsc8.com/?special=%3Cscript%20src=%22https://somedomain.com/somescript.js%22%3E%3C/script%3E . All browsers behave differently yet again:
- Chrome does not load any content. No output in Network or Console tabs.
- Firefox loads all the content including the offending script. No output in console.
- Microsoft Edge and IE11 do not load any content. The console shows error message and the network tab shows the request.
As you can see each browser behaves differently. I would say in this case FireFox is the worst. We are unable to get full protection from all browsers with the X-XSS-Protection. This should show us that there is no silver bullet. We would need to implement multiple protections to remedy the XSS vulnerability.
You can use a third party site like securityheaders.io to evaluate your site.
If you have any questions or concerns, please get in touch with me. (@akshaysura13 on twitter or on Slack).