Cross-Site Scripting Attack (XSS) – A Major Security Threat for Agile Environments

In the current times, websites rely more on complex web applications to deliver different output or content to a wide variety of users according to set of preferences and specific needs. This empowers organizations to provide better value to their customers and prospects. Further, companies are willing to move their applications to the web not to just improve customer interactions, but also to lower business processing costs, and accelerate outcomes. However, today’s dynamic websites suffer from serious vulnerabilities, making organizations helpless and prone to attacks on their sensitive data and information resources. And, at this juncture, security becomes an integral component of the application development process, and a strategic necessity from the organization’s standpoint.

The table below depicts the statistics provided by the Web Hacking Incident Database for 2013 (WHID), which clearly classifies the major types of vulnerabilities along with their proportion as the most likely cause of the attacks:

Sr. No

Type of Vulnerability



Cross-Site Scripting



SQL Injection



Insufficient Authorization



Insufficient Transport Layer Protection



Brute Force



Cross-site Request Forgery



Content Spoofing



Information Leakage





With reference to above statistics, it is evident that whilst many different attack methods exist, Cross-Site Scripting and SQL Injection are considered to be most popular, severe and draws some serious attention to be paid to them during web-application design, implementation, and maintenance. So, having said that it is very important for us to give a thoughtful consideration primarily to understand what exactly a cross-site scripting attack is, the types of XSS attacks, how readily they are implemented to make an web-application vulnerable, and the preventive and/or corrective measures to counteract the XSS attack. The sections below are intended to provide the requisite awareness and understanding along the lines discussed above.

Cross-Site Scripting

In general, cross-site scripting refers to a hacking technique that leverages vulnerabilities in the code of a web application, allowing an attacker to send malicious content from an end-user and collect some type of data from the victim. Cross-site scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques.

Now, understanding web-application from a technical standpoint: “A web page usually contains both text and HTML markup that is generated by the server and interpreted by the client browser. Generally, websites that generate only static pages are able to have full control over how the browser interprets these pages. But, websites that generate dynamic pages do not have complete control over how their outcomes are interpreted by the client and hence this becomes an ideal situation for introducing some mistrusted content into a dynamic page, which neither the website nor the client has enough information to recognize that such mistrusted content is already in place and take some protective measures to counteract them.”

Cross-site scripting allows an attacker to embed malicious JavaScript, VB-Script, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the end-user by executing the script on their system in order to gather some sensitive data. So, using XSS the attacker might compromise private information, manipulate or steal cookies, create requests that are intended to mislead a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink embedded with malicious content and it is distributed via any possible means on the internet.

Sr. No

Vulnerable Web/HTML page Attributes

XSS Approach


<BODY> tag

The <BODY> tag can contain an embedded script by using the ONLOAD event, as shown below:


<IMG> tag

<IMG SRC=javascript:alert(‚XSS‘);>


<IFRAME> tag

The <IFRAME> tag generally enables HTML to be imported into a page.
This imported HTML can contain a script as shown below:


<INPUT> tag

If the TYPE attribute of the <INPUT> tag is set to BUTTON, then it can be manipulated to embed a script as shown below:
<INPUT TYPE=button Onclick=javascript:alert(‚XSS‘);>


<LINK> tag

It is used to link external style sheets and could contain a script
as shown below:
<LINK REL=style.css HREF=javascript: alert(‚XSSAttack‘);>


<TABLE> tag

Most commonly, the BACKGROUND attribute of the table tag can be
exploited to refer to a script as shown below:
<TABLE BACKGROUND=“javascript:alert(‚XSS‘)>


<DIV> tag

The <DIV> tag can also specify a background and therefore can be exploited by embedding a script as shown below:


<EMBED> tag

The hacker can place a malicious script inside a flash file, and it can be injected in the following manner:
<EMBED SRC= AllowScriptAccess=always>

Types of Cross-Site Scripting Vulnerabilities

There are basically two major types of XSS vulnerabilities:

  • Reflected (Non-Persistent) Attack – In a reflected XSS attack, the attacker persuades a victim to click on a specially crafted link that makes a request to a vulnerable web- server. This enables the attacker to run arbitrary code in the victim’s web-browser. In this type of attack, the attacker has to target each victim individually.
  • Stored (Persistent) Attack – In a stored attack, the attacker embeds the malicious or harmful code in a web-page or other data stored on a vulnerable server. Further, the attacker’s code will then run in the browser of everyone who visits the compromised web-page. Due to the underlying potential to exploit multiple victims with minimal effort, stored attacks are generally considered to be more dangerous than reflected attacks.

Example of a Cross-Site Scripting Attack – Explained.

Here is a classic example to illustrate a typical cross-site scripting attack. Imagine a search engine site Generally, the web-page of the search engine typically comprises a simple text field followed by a ‘submit’ button into which the user inputs/keys the required search string ‘what is XSS’ and clicks on the submit button. Then it takes the user to the results page which displays both the matching results and the actual search string entered. Now, if we carefully look at the URL of the search results page, it actually contains the website address along with the search string variables appended to it with some junk characters in between.

When all this is put together, the URL appears as shown below:

In our next attempt to search for another result, let us try putting the below mentioned code snippet in the text field of the search page and submit it.

<script type='javascript'>;

alert("This is a XSS Attack")


Now, after page submission, if we take a close look at the URL of the search results page, it is actually encoded and the resulting URL would be something like:

So, when the results page is finally loaded, the search engine would probably display no results for the search string entered, but it will display a typical javascript alert which has been injected into the page by using the XSS vulnerability. It is at this juncture that the search engine’s web-page is considered to be highly susceptible and open to an XSS attack.

Having explained the above, it is evident that Cross-Site Scripting (XSS) attacks are amongst the most common types of attacks against web applications. Although all XSS attacks fall under the same category, but there are different types of techniques employed during the implementation of XSS operations, which shows that there are multitude of tactics that exploit a variety of other attack. Importantly, attack methods such as Information Disclosures, Content Spoofing, and Stolen Credentials etc. could definitely exist due to the side-effects of an XSS attack. The pie-chart below formulated by WHID (2013) clearly depicts the different types of attack methods and percentage possibility of their occurrence:


Preventing Cross-Site Scripting Attacks – Conceptualized.

The two most common and useful XSS prevention mechanisms are namely Filtering and Escaping.

Filtering for XSS

As discussed above, XSS attacks infect the website via some form of unintended user input. Usually, there are various channels which exist in order for an XSS attack code to come in place, they could be a simple <form> submitted by end-users, or a more complex route such as a JSON script, or a typical XML web service, or even an exploited cookie. So, in all such cases the web developer should be cautious and aware that the data is coming from an external source and therefore must not be trusted, and should think carefully and apply judgment before using them.

In such situations the simplest and, arguably, easiest form of XSS protection would be to pass all external data through a filter which will detect and remove the dangerous keywords, such as the
unfamiliar <script> tag, JavaScript commands, CSS styles, and other dangerous HTML markup (which contain certain event handlers).

Generally, many of the web developers choose to implement their own custom filtering mechanisms by formulating some server-side code (in PHP, ASP, or some web-enabled development language) to search for those unknown keywords and then replace them with just empty strings. This technique makes use of regular expressions as the basis for doing this filtering and making the replacing technique much more robust. Although incorporating this technique is not a bad idea, unfortunately the hackers are presumed to have much more experience than the web developers, and, hence, they often manage to bypass these simple filters by using some sophisticated techniques such as encoding, character (unicode) variations, line breaks, and having null characters in strings. These techniques must all be catered for and that is why it is recommended to use some sort of library that has been tried and tested by the community at large.

Currently, many libraries exists. so there is a very wide list to choose from, but the governing factor behind choosing a right library will primarily depend on the backend technology that your web server uses. Likewise, what is important is that you choose a library that is regularly maintained by a reliable source. As it is very obvious that XSS techniques keep changing and new ones keep emerging all the time so it is essential that custom web filters are updated periodically to keep up with the changing dynamics of the attacks.

Sr. No




XSS Project

Based on Java, it is very helpful for filtering all known XSS attacks from the HTML code.


HTML Purifier

A library facilitated by PHP. It offers better facilities than other con-
ventional filters. It ensures compliance with web/HTML standards.


HTML Markdown

It is a Perl library which converts text from users to standard and clean XHTML. However, It does not explicitly talk about XSS prevention.

There are some useful tools/libraries readily available that facilitate filtering for XSS. The table below summarizes their details:

The only drawback with the above filtering techniques is that even legitimate text is often subjected to filtering and removed because it will certainly have some keywords that might be in the forbidden list used by the tools/libraries internally. To avoid this, it is advisable to liberalize the filters/libraries by using HTML, script and CSS escaping techniques.

Escaping for XSS

This is primarily the best means of weakening an XSS attack. So, when performing escaping, you are constructively telling the browser that the data you are sending should be treated as data and not to be interpreted in any other way. So, even if an attacker manages to put a script on your page, the victim will not be affected because the browser will not execute the script if it is properly escaped. Generally, in HTML we can escape suspicious characters by using the &# sequence followed by its character code.

The table below provides the list of most commonly used escape codes for HTML:

Sr. No


Escape Codes
























Currently, the most popular escaping library available is the ESAPI provided by OWSAP. It can be readily plugged into any technologies such as JAVA, .NET, PHP, Cold Fusion and Python etc.

When to use HTML Escaping

The HTML escaping technique can be readily used and/or implemented in the following scenarios:

Sr. No




When untrusted data is inserted between HTML opening and closing tags, e.g. <BODY>, <DIV>, <TABLE> etc.



When untrusted data is inserted in a place where javascript is present, e.g. attributes such as STYLE and event handlers such as ONLOAD, ONMOUSEOVER etc.



When untrusted data is inserted inside the CSS styles.

<DIV STYLE=background-


Preventive Measures to avoid XSS Attacks

Here is a list of some generic measures that users can take to protect themselves from XSS and other attacks:

  • Restrict Untrusted Javascript – generally, allowing all java-script to run will expose users to XSS attacks. These can be prevented by allowing javascript to run only if it comes from a domain that the user explicitly trusts.
  • Use Built-in Browser Protections – in recent times some browsers have begun to incorporate XSS protection inherently. For example I.E-8 is inbuilt with XSS filter as well as a screen filter that protects from malicious websites.
  • Restrict External Websites from Requesting Internal Resources – generally allowing external websites to force a browser to request internal resources can allow an attacker to pin an attack on a vulnerable internal website.
  • Maintain System Hygiene – it is very important to keep systems and applications up to date with updates and patches, protected from malware, and securely configured.

Importantly, from the system developer’s standpoint, the most effective way to get rid of XSS vulnerabilities is to ensure that developers understand the dangers of XSS attacks and have tools that both rescue and allow them to create secure web applications without hindering their productivity. This can be achieved by adhering to the following practices and/or measures:

  • OWASP XSS Prevention Cheat Sheet – the OWASP XSS prevention cheat sheet has a lot of useful information on XSS attacks and how to process user input safely.
  • Blacklisting Vs Whitelisting – these are two basic techniques to mitigate XSS attacks and are also used to sanitize data. Blacklisting uses a list of known bad data to block illegal content from being executed, whereas whitelisting uses a list of known good data to allow only that content to be executed. Whitelisting allows for a much stronger security solution, but it requires some defined expertise and there is a need to learn how to implement it. However, once mastered, whitelisting is very effective at stopping XSS attacks.
  • Using Web Vulnerability Scanners – there are many tools and/or services that scan websites for XSS vulnerabilities. These tools and/or services crawl through websites and check code that takes user input to see if it is susceptible to XSS attacks. These tools may not catch all XSS vulnerabilities, but they may at least help us find the vulnerable areas.
  • Implementing OWASP Enterprise Security API (ESAPI) – the ESAPI library is an implementation of methods, including whitelisting techniques that process user input safely. It is available in a number of modern programming languages such as Java EE, PHP, .NET, Cold Fusion, and Python etc. The ESAPI library requires the developer to understand which methods are susceptible to XSS attacks and to replace them with safe implementations accordingly.

Narayana Maruvada

Narayana Maruvada is a computer science and engineering graduate, currently working as System Analyst – QA with ValueLabs. He has more than 7 years of experience working on both developing and testing web-based applications. A major area of work and...
Read more about Narayana Maruvada