Secure Sitecore : Cross Site Scripting (XSS) Vulnerability Findings

Lately I have been focussed on OWASP Top 10 security guidelines and locking down sites. The next one on the list is Cross Site Scripting (XSS). According to OWASP:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

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).

These tests were done on a base install of Sitecore where no changes were made to the Web.config and Sitecore.config. As of .NET 4.5 the Request Validation does not trigger until the data is requested. You could always use the Request.Unvalidated to access the potentially unsafe values coming in.

It is important to know that not all browsers are alike. Some are advanced in their implementations and some are not. Your solution has to deter potential risks from any browser.

First, load the site http://local.testsc8.com on all browsers to make sure its loading:

Following that, lets load it with some malicious params, http://local.testsc8.com/?q=<script>

What happened here? Seems like Chrome and Firefox are not even recognizing what the input is, where as IE 11 and MS Edge are. But this is not true. lets inspect the session using Fiddler.

What you can see is that each browser interprets the url differently. We typed in http://local.testsc8.com/?q=<script> but each of the browsers interpreted it differently than what I typed in except IE11. Chrome and Firefox encoded it immediately. Microsoft Edge encoded the ending > but not the beginning <.

What this shows is that even though Chrome and Firefox encoded the input, it did not make the input safe. If we on the code behind did not interpret the incoming parameters incorrectly, we could cause a lot of damage and let a potential hacker get in.

Next, lets put in a simple form in a view on the default install and see how that matches up. Lets input <script> in the text box.

All browsers transmitted the data and we were able to catch all exceptions. Lets try a few more combinations. (%3Cscript%3E)

Now for <script%3E.

I also want to mention the below setting:

Setting it to true is not going to do anything unless you want to set the requestValidationMode to 2.0 which I do not intend to. I want the requestValidationMode to 4.5. Also the httpRuntime is misspelled ;).

In all of this even with flag as true for validateRequest, the admin works and is able to save items etc.

In the next post we will see if we can add on more security for Querystring and Form.

If you have any questions or concerns, please get in touch with me. (@akshaysura13 on twitter or on Slack).