Cross-Site Scripting attack (XSS), is one of the top 10 OWASP most critical web application security risks.
As a developer I pay extra attention to this attack, because it is 100% caused by a vulnerable code, and it is 100% developer responsibility to protect against this attack.

Introduction

Cross-Site Scripting (XSS) attack occurred when a malicious scripts inject itself into a trusted website. For example, you are logged into your bank account, and if a malicious script find itself into this website, then it can steals all your data in memory, local or session storage, and your cookies.

Cause of XSS

XSS caused mainly by malicious data entered into the web application, and not being validated, and then processed by the application, either on:

  • Server side.
  • Web client side.
  • Plugins (ActiveX, Java, VBScript, Flash or HTML Scripts).

This malicious data can then be reflected back to the browser without encoding or escaping, and maybe saved into the database, to be persistent.
It doesn’t stop on data entered using form data, or html input data only, but include anything communicating to the web application, including URL, Headers, and Cookies.
Any surface where the application is expecting input (request url, headrs, cookies, post body…), can be a place where someone inject a malicious JavaScript code, that can steal all session information (local storages, cookies, …), or performing other malicious operations on the user’s machine under the guise of the vulnerable site. The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute.

XSS types

XSS attacks can be divided into two main types as follows:

  1. Reflected XSS attack.
  2. Stored XSS attack.

We can divid them as well, into:

  1. server-side code flaws
  2. DOM-based code flaws.

Stored XSS Attacks

Stored XSS is where the hacker find a way to store the XSS infected code into the server data, and then the data being reflected back to the browser.
A common scenario, is a forum, or comment list on a website, where other users share the view of all messages, or comments on the page. So, the hacker will inject the malicious code into the comment/forum post field.
When other users open the forum post, or see the comments, that malicious code will be run on their browser, getting access to all their site information.
This type is called as well Persistent XSS or Type-I XSS.

Reflected XSS Attacks

Injected script is using the vulnerability where server-rendered html page, uses any part of input request into rendering the webpage.
Let us discuss this example: Your application is handling a url that has an ID in the url as follows:

https://my-vulnerable-app.com/products/{id}

The server-side rendering of the application is displaying the parameter on the html page as follows:

<div>Product ID: {id}</div>

The hacker can just submit a url as follows:

https://my-vulnerable-app.com/products/<script> console.log(document.cookie); </script>

Reflected attacks are delivered as links in emails, or from links on other websites, and when the victim click on the link to open the link in his/her browser, then will execute the code.

Prevent XSS

To prevent XSS follows these rules:

  1. Sanitize data input.
  2. Sanitize data output.

Sanitize data input:

This process called sanitize your input data.

Sanitize data output:

Any HTML rendering for data should be done on sanitized data. This can be done as follows:

  1. HTML escape before insert data into HTML content.

Whenever you do something like this, do HTML escape on the content:

<body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>
<div>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</div>
  1. Don’t use inline JavaScript Inline JavaScript is when you put JS code in HTML or in an attribute, as follows
<script>alert('something');</script>
<button onclick="alert('anything')">push me</button>