Cross Site Scripting, also known as XSS, is a type of injection problem where an attacker is able to inject a client side script. This type of attack is commonly exploited in web based applications. In a Cross Site Scripting attack, an attacker can perform actions suchs as:

[icon icon_name=”icon-bolt”] Retrieve sensitive information stored in cookies, such as a session ID. [/icon]
[icon icon_name=”icon-bolt”] Control the users web browser, for example redirect a user to a page with malicious content. [/icon]
[icon icon_name=”icon-bolt”] Execute a remote shell [/icon]
[icon icon_name=”icon-bolt”] Log a user’s key strokes (key logger) [/icon]
[icon icon_name=”icon-bolt”] Make it look like the website is defaced [/icon]

There are three types of Cross Site Scripting attacks:

[icon icon_name=”icon-unlock”] Reflected Cross Site Scripting (a.k.a. Non Persistent Cross Site Scripting) [/icon]
[icon icon_name=”icon-unlock”] Persistent Cross Site Scripting (a.k.a. Stored Cross Site Scripting) [/icon]
[icon icon_name=”icon-unlock”] DOM Based Cross Site Scripting [/icon]

Reflected Cross Site Scripting
In order for this type of Cross Site Scripting to be executed, the attacker needs to trick the victim in visiting a link. The attacker will prepare a link with a payload which will be executed when the victim visits the link. This type is found commonly found in web applications.

Persistent Cross Site Scripting
The attacker will store its payload in a database (or any other form of storage). Each time a victim visits a specific page within a web application, the payload will be executed without the knowledge of the victim. This is the most dangerous form of Cross Site Scripting.

DOM Cross Site Scripting
DOM-Based Cross-Site Scripting allows to an attacker to work on a victim’s local machine.

The DOM Based XSS exploits these problems on users local machines in the following way:

    • The attacker creates a well build malicious website.
    • The victim opens that site.
    • The victim has a vulnerable HTML page on their machine.
    • The attacker’s website sends commands to the vulnerable HTML page.
    • The vulnerable local page execute that commands with the victim’s privileges on that machine.
    • The attacker gains control over the victim’s machine.

Preventing XSS Attacks
There are several methods, which needs to be combined, to prevent an attacker from successfully performing an XSS attack:

[icon_list] [icon icon_name=”icon-check”] Input & Output validation [/icon] [icon icon_name=”icon-check”] Encoding & Escaping [/icon] [icon icon_name=”icon-check”] Implement security headers [/icon] [/icon_list]

Input & Output Validation
Input & output validation is the first line of defense for any web application. All parameters received by a user and sent to a user should be validated. Please note that all parameters should be checked, not only the input fields that a user can see. This includes cookies and referers.

Input validation should always performed on the server-side. From a security perspective, client side validation is considered no validation and should only be used for user experience. As XSS happens on output when unfiltered data hits the user’s web browser. Untrusted data may originate from a variety of locations, including your own database. Therefore it is important to always perform both input and output validation.

Encoding & Escaping
Encoding is a method to process content that is about to be sent to the user’s browser so that any potentially dangerous characters are made safe.

A browser should never guess content encoding of a web application, therefore it is important to always set the encoding type. This can be done either by a response header or by meta tags, both options can be used simultaneously.

Implementing Security Headers
As part of the web server hardening it is highly recommended to implement several security headers. Two of the following headers could prevent Cross Site Scripting attacks:


The Content Security Policy is a standard HTTP header that allows website owners to declare approved sources of content that browsers should be allowed to load on that page. If this header is present in the HTTP response, a compliant client enforces the declarative white list policy for JavaScript, CSS, HTML frames, fonts, images and embeded objects.

The Content-Security-Policy header looks like:

Valid policy keywords that can be used are:

‘none’: Refers to the empty set; that is, no URLs match.
‘self’: The host from which the protected document is being served, including the same URL scheme and port number.
‘unsafe-inline’: Allows the use of inline resources such as inline <script> elements, javascript: URLs, inline event handlers and inline <style> elements.
‘unsafe-eval’: Allows the use of eval()and similar methods for creating code from strings.


The X-XSS-Protection header let the browser know to enable its XSS protection. The browser tries to detect whether an XSS attack occurred, if so it will modify the page to block the attack and display a warning to the user.

The X-XSS-Protection header looks like:

The XSS filter can be set on or off (1 or 0). There is an optional parameter called mode. If mode has been set to block, the page will not be displayed at all.

Payloads for testing Cross Site Scripting vulnerabilities can be found here.

Share on Facebook2Share on Google+0Tweet about this on TwitterShare on LinkedIn0Email this to someonePin on Pinterest0Share on Reddit0Digg thisShare on Tumblr0Share on Yummly0Share on StumbleUpon0Flattr the author