Cross-Site Scripting Prevention

Cross-site scripting is vulnerability in web applications which allows hackers to inject JavaScript code in the form fields whose values are not sanitized properly. These values are either saved in database or executed later when they used in other areas of application or displayed immediately in page. As defined by Open Web Application Security Project (OWASP), there are two types of attacks classified as stored XSS and reflected XSS, respectively.

To understand XSS better, let us take an example. We allow users to send messages to pet owners. At this point, if user tries to add HTML tags to the message then the user gets an error as shown in Figure 1. This error is throwing because ASP.NET verifies all input fields to prevent XSS and by default does not allow users to post any HTML tag to server.

Figure 1. ASP.NET prevents XSS mechanism and disallows HTML post to server

Now, if we really need to allow the users to post the HTML tags to server then we can modify behavior by adding ValidateInput as false to the send action method as shown in Figure 2. The problem is that it will disable all the XSS validation for all fields.

Figure 2. Disabling All XSS Validation

Better approach is allowing the HTML tags in specific fields. In this example, only field in which we allow HTML tags is the Message field. To achieve this, we need to remove ValidationInput = false attribute from action method and add AllowHtml attribute to the field in the view model as shown in Figure 3. We have modified the send view to show the values posted after user sent the message. When user sends the message then we get result shown in Figure 2.

Figure 3. Allowing HTML Tags in Message Field

The application has opened one door to let users enter HTML tags, including <script> tags. The user can enter <script type="text/javascript">alert("Evil Script");</script> in the field and the result will be as shown in Figure 4.

Figure 4. JavaScript injected in Message field

WebKit based browsers like Google Chrome and Safari have integrated XSS validation module which is called XSS Auditor which can prevent execution of <script> tags. The Chromium Blog article “Security in Depth: New Security Features” describes behavior of XSS Auditor at the time known as XSS filter as follows:

XSS filter is similar to the ones found in Internet Explorer 8 and NoScript. Instead of layered on top of browser like those filters, the XSS filter is integrated into WebKit, which Google Chrome uses for rendering the webpages. Integrating XSS filter into rendering engine has two benefits:

1. The filter can catch scripts right before they executed, making easier detection some tricky attack variations.

2. The filter can be used by all WebKit based browser, including Safari and Epiphany.

Google Chrome also acknowledges that there are some other ways of bypassing the XSS filters. However, it is always improving the technology, so over time these scenarios should be avoided.

For example, In Google Chrome, message entered previously produces an error in developer tool console as shown in Figure 5.

Figure 5. XSS Auditor module in Google Chrome