A Complete Guide to Cross Site Scripting (XSS) Attack, how to prevent it, and XSS testing.
Cross Site Scripting (XSS) is one of the most popular and vulnerable attacks which is known by every advanced tester. It is considered as one of the riskiest attacks for the web applications and can bring harmful consequences too.
XSS is often compared with similar client-side attacks, as client-side languages are mostly being used during this attack. However, XSS attack is considered riskier, because of its ability to damage even less vulnerable technologies.
This XSS attack tutorial, we will give you a complete overview of its types, tools and preventive measures with perfect examples in simple terms for your easy understanding.
Introduction to XSS Attack
Cross Site Scripting attack is a malicious code injection, which will be executed in the victim’s browser. Malicious script can be saved on the web server and executed every time when the user calls the appropriate functionality. It can also be performed with the other methods – without any saved script in the web server.
The main purpose of this attack is to steal the other user's identity data – cookies, session tokens and other information. In most of the cases, this attack is being used to steal the other person‘s cookies. As we know, cookies help us to log in automatically. Therefore with stolen cookies, we can login with the other identities. And this is one of the reasons, why this attack is considered as one of the riskiest attacks.
XSS attack is being performed on the client side. It can be performed with different client-side programming languages. However, most often this attack is performed with Javascript and HTML.
How is XSS Being Performed?
Cross Site Scripting attack means sending and injecting malicious code or script. Malicious code is usually written with client-side programming languages such as Javascript, HTML, VBScript, Flash, etc. However, Javascript and HTML are mostly used to perform this attack.
This attack can be performed in different ways. Depending upon the type of XSS attack, the malicious script may be reflected on the victim’s browser or stored in the database and executed every time, when the user calls the appropriate function.
The main reason for this attack is inappropriate user’s input validation, where malicious input can get into the output. A malicious user can enter a script, which will be injected into the website’s code. Then the browser is not able to know if the executed code is malicious or not.
Therefore malicious script is being executed on the victim's browser or any faked form is being displayed for the users. There are several forms in which XSS attack can occur.
Main forms of Cross Site Scripting are as follows:
- Cross Site Scripting can occur on the malicious script executed at the client side.
- Fake page or form displayed to the user (where the victim types credentials or clicks a malicious link).
- On the websites with displayed advertisements.
- Malicious emails sent to the victim.
This attack occurs when the malicious user finds the vulnerable parts of the website and sends it as appropriate malicious input. Malicious script is being injected into the code and then sent as the output to the final user.
If the search field is vulnerable, when the user enters any script, then it will be executed.
Consider, a user enters a very simple script as shown below:
<script>alert(‘XSS’)</script>
Then after clicking on the “Search” button, the entered script will be executed.
As we see in the Example, the script typed into the search field gets executed. This just shows the vulnerability of the XSS attack. However, a more harmful script may be typed as well.
Many testers mix up Cross Site Scripting attack with Javascript Injection, which is also being performed on the client side. In both, the attacks malicious script is being injected. However, in the XSS attack case <script> tags are not necessary to execute the script.
For Example:
<body onload=alert(‘something’)>;
Also, it can be a script executed on the other event.
For Example: On a mouse hover.
<b onmouseover=alert(‘XSS testing!‘)></b>
Let us analyze another Example: Consider, we have a page, where the latest book review is being displayed on the website.
The code of this page will look as shown below:
print "<html>" print "<h1>Latest book review</h1>" print database.latestReview print "</html>"
Therefore, in the review field if a malicious user types something harmful, then it will be loaded on this page.
For Example: Consider, that in the review field if a hacker types the below code.
<script>destroyWebsite();</script>
Then on the page load function destroyWebsite(); would be called and it will perform its harmful actions.
As most of us know, this attack is mostly used to gather the other person’s cookies, which can be used to log in with the other identities. Let us analyze another example of possible XSS script with possible cookies theft.
For Example, through the vulnerable website’s field, the hacker injects the appropriate code.
<script type=”text/javascript”> var test=’../example.php?cookie_data=’+escape(document.cookie); </script>
As seen in the indicated Example, cookies are escaped and sent to example.php script’s variable ‘cookie_data’. If the malicious user would inject this script into the website’s code, then it will be executed in the user’s browser and cookies will be sent to the malicious user.
Types of Cross Site Scripting Attacks
The prime purpose of performing XSS attack is to steal other person’s identity. As mentioned, it may be cookies, session tokens, etc. XSS also may be used to display faked pages or forms for the victim. However, this attack can be performed in several ways.
This attack is divided into three main categories as shown below:
#1) Reflected XSS – This attack occurs, when a malicious script is not being saved on the web server but reflected in the website’s results.
#2) Stored XSS – This attack occurs when a malicious script is being saved on the web server permanently.
#3) DOM – This occurs, when the DOM environment is being changed, but the code remains the same.
Let's take an in-depth look at them.
#1) Reflected XSS
This occurs when the malicious results are being returned after entering the malicious code. Reflected XSS code is not being saved permanently. In this case, the malicious code is being reflected in any website result. The attack code can be included in the faked URL or HTTP parameters.
It can affect the victim in different ways – by displaying faked malicious page or by sending a malicious email.
Let us analyze an Example: Consider, we have a login page, where the user has to type his username and password.
In some websites when wrong credentials are typed, an error message like “Sorry your username or your credentials are wrong” will be displayed.
In this Example, the username is a parameter that is typed by the user in the login form. Including the username parameter in the output is a mistake. This way an attacker can type the malicious script instead of the correct username or email address.
For Example, it may be a script, which is sent to the user's malicious email letter, where the victim may click the faked link.
#2) Stored XSS
This attack can be considered riskier and it provides more damage.
In this type of attack, the malicious code or script is being saved on the web server (for example, in the database) and executed every time when the users will call the appropriate functionality. This way stored XSS attack can affect many users. Also as the script is being stored on the web server, it will affect the website for a longer time.
In order to perform stored XSS attack, the malicious script should be sent through the vulnerable input form (For Example, comment field or review field). This way the appropriate script will be saved in the database and executed on the page load or appropriate function calling.
Consider, we have a page where the latest user opinion is being loaded. Therefore, in the opinion or comment field would be typed with the script as shown below.
<script>alert(document.cookie)</script>
It will be saved in the database and executed on the page load, as the latest user opinion will be displayed on the page. If a website is vulnerable for XSS, then on the page load popup window with cookies will be displayed. This script is quite simple and less harmful. However, instead of this script, a more harmful code may be entered.
For Example, cookies may be sent to the malicious user or a fake page may be displayed in the victim’s browser.
#3) DOM XSS
This type of attack occurs when the DOM environment is being changed, but the client-side code does not change. When the DOM environment is being modified in the victim’s browser, then the client side code executes differently.
In order to get a better understanding of how XSS DOM attack is being performed let us analyze the following Example.
Consider, there is a webpage with URL http://testing.com/book.html?default=1. As we know, “default” is a parameter and “1” is its value. Therefore, in order to perform XSS DOM attack, we would send a script as the parameter.
For Example:
http://testing.com/book.html?default=<script>alert(document.cookie)</script>
In this Example, the request is sent for the page book.html?default=<script>alert(document.cookie)</script> to testing.com. Therefore for that page, a DOM object is being created by the browser, where the document location object will contain the appropriate string.
http://testing.com/book.html?default=<script>alert(document.cookie)</script>
This way the DOM environment is being affected. Of course, instead of this simple script, something more harmful may also be entered.
How to Test Against XSS?
Firstly, in order to test against XSS attack, black box testing can be performed.
It means, that it can be tested without a code review. However, code review is always a recommended practice and it brings more reliable results too. From my software testing experience, I would like to add, that if a good black box testing technique is selected and performed accurately, then this should be much enough.
While starting testing, a tester should consider which website’s parts are vulnerable to the possible XSS attack.
It is better to list them in any testing document and this way we will be sure, that nothing would be missed. Then, the tester should plan for what code or script input fields have to be checked. It is important to remember, what results mean, that application is vulnerable and it analyzes the results thoroughly.
While testing for possible attack, it is important to check how it is being responded to the typed scripts and is those scripts executed or not etc.
For Example, a tester may try to type in the browser script like:
<script>alert(document.cookie)</script>
If this script is being executed, then there is a huge possibility, that XSS is possible.
Also while testing manually for possible Cross Site Scripting attack, it is important to remember, that encoded brackets should also be tried.
For Example:
%3cscript%3ealert(document.cookie)%3c/script%3e
Some people try to protect the websites and systems from various attacks by changing the brackets into double.
For Example, if the input field would be typed with bracket “<”, then it would be changed to double “<<”. Therefore, it is important to remember, that testing with encoded brackets should also be executed.
You should not forget to test the website’s URL.
For Example, we have a request:
http://www.testing.com/test.asp?pageid=2&title=Testing%20Title
If this attack is possible, then the HTML code will include <h1>Testing Title</h1>. If this vulnerability is present in the web application, an indicated text will be inserted in <h1></h1> tags.
Trying to pass some code through HTTP request as this is also a method to check if this attack is possible.
Generally, while testing for possible XSS attack, input validation should be checked and the tester should be conscious while checking the website’s output. Also if a code review is being performed, it is important to find how input can get into the output.
XSS Testing Tools
As Cross Site Scripting attack is one of the most popular risky attacks, there are a plenty of tools to test it automatically. We can find various scanners to check for possible XSS attack vulnerabilities – like, Nesus and Nikto. Both of which are considered as quite reliable.
From my software testing career, I would like to mention SOAP UI tool. SOAP UI can be considered as a quite strong tool for checking against the possible XSS attacks. It contains ready templates for checking against this attack. It really simplifies the testing process.
However, in order to test for this vulnerability with SOAP UI tool, API level testing should already be automated with that tool. Another solution to test against XSS can be browser plugins. However, plugins are considered as quite a weak tool to check against this type of attack.
Even while testing automatically, the tester should have good knowledge of this attack type and should be able to analyze the results appropriately.
Good knowledge is also helpful while selecting the testing tool. Also, it is important to know, that while performing scanning for security vulnerabilities with an automatic tool, testing manually is also a good practice and this way the tester will be able to see the results and analyze them.
Recommended Tool:
#1) Kiuwan
Find and fix vulnerabilities in your code at every stage of the SDLC.
Kiuwan is compliant with the most stringent security standards including OWASP, CWE, SANS 25, HIPPA, and more. Integrate Kiuwan in your IDE for instant feedback during development.
Kiuwan supports all major programming languages and integrates with leading DevOps tools.
Comparison with Other Attacks
XSS is considered to be one of the riskiest attacks, as its main purpose is to steal the website’s or system’s user identities. Also, XSS attack can be performed with different client-side languages like Javascript, HTML, VBScript, Flash, etc. And this makes it more harmful and widespread than the other possible attacks.
Testing for XSS attack is quite similar to testing for the other possible client-side attacks. However, it is important to remember what additional cases should be checked while testing for XSS.
Another thing, that makes this attack riskier is the possibility to be stored in the web service – this way it can affect many users for a longer period of time. XSS sometimes can be performed to even less vulnerable systems and its vulnerabilities are sometimes difficult to be found.
Also, while comparing with the other attacks, XSS has many ways to be performed and affect the website as well.
Ways to Prevent XSS
Though this type of attack is considered to be one of the most dangerous and risky one, still a preventing plan should be prepared. Because of the popularity of this attack, there are quite many ways to prevent it.
Commonly used main prevention methods include:
- Data validation
- Filtering
- Escaping
The first step in the prevention of this attack is Input validation. Everything, that is entered by the user should be precisely validated, because the user’s input may find its way to the output. Data validation can be named as the basis for ensuring the system’s security. I would remind, that the idea of validation is not to allow inappropriate input.
Therefore it just helps to reduce the risks, but may not be enough to prevent the possible XSS vulnerability.
Another good prevention method is user’s input filtering. The idea of the filtering is to search for risky keywords in the user’s input and remove them or replace them by empty strings.
Those keywords may be:
- <script></script> tags
- Javascript commands
- HTML markup
Input filtering is quite easy to practice. It can be performed in different ways too.
Like:
- By developers who have written server-side code.
- Appropriate programming language’s library is being used.
In this case, some developers write their own code to search for appropriate keywords and remove them. However, the easier way would be to select appropriate programming languages library to filter the user’s input. I would like to comment, that using libraries is a more reliable way, as those libraries were used and tested by many developers.
Another possible prevention method is characters escaping. In this practice, appropriate characters are being changed by special codes. For Example, < escaped character may look like <. It is important to know, that we can find appropriate libraries to escape the characters.
Meanwhile, good testing should not be forgotten as well. It should be invested in good software testers knowledge and reliable software testing tools. This way good software quality will be better assured.
Prevention According to Technologies
As already discussed, filtering and characters escaping are the main prevention methods. However, it can be performed differently in different programming languages. Some programming languages have appropriate filtering libraries and some do not.
It should be mentioned, that filtering can be performed quite easily in Java and PHP programming languages, as they have appropriate libraries for it.
Java technology is quite widely used, therefore there are many solutions to it. If you are using Spring technology and if you would like to escape HTML for the whole application, then you have to write the appropriate code in the project’s web.xml file.
<context-param> <param-name>defaultHtmlEscape</param-name> <param-value>true</param-value> </context-param>
This code will switch HTML escaping for the entire application.
If you would like to switch HTML escaping for the appropriate page’s forms, then the code should be written as follows:
<spring:htmlEscape defaultHtmlEscape="true" />
There are many ready XSS filters in the form of a .jar file. I would remind, that .jar file have to be added to your project and only then its libraries can be used. One such XSS filter is xssflt.jar, which is a servlet filter. This .jar file can be easily downloaded from the internet and added to your project.
This filter checks every request that is sent to the application and cleans it from a potential injection.
When an external.jar file is added to the project, it also has to be described in the web.xml file:
<filter> <filter-name>XSSFilter</filter-name> <filter-class>com.cj.xss.XSSFilter</filter-class> </filter>
Another possible solution is ESAPI library. ESAPI library is compatible with many programming languages. You can find ESAPI libraries for Java and PHP programming languages. It is an open source and free library, which helps to control the application’s security.
XSS Cheat Sheets
XSS Cheat Sheets can be very helpful for cross site scripting prevention. It is a guideline for the developers on how to prevent XSS attacks. The rules are very helpful and should not be forgotten while developing. XSS Cheat Sheets can be found in internet communities such as OWASP (The Open Web Application Security Project).
Different types of Cheat Sheets:
- XSS Prevention Cheat Sheet
- DOM XSS Cheat Sheet
- XSS Filter Evasion Cheat Sheet
The main guideline would be XSS Prevention Cheat Sheet, as it provides common rules for XSS attack prevention. If you would follow DOM XSS Cheat Sheet and XSS Filter Evasion Cheat Sheet rules, you still would have to follow XSS Prevention Cheat Sheet.
As stated, XSS Prevention Cheat Sheet can be found in the OWASP community. This Cheat Sheet provides us with a list of rules, that would help us to reduce the risks of possible XSS attacks. It is not only the coding rules but also the security vulnerabilities on a prevention basis.
Few of the rules include:
- Untrusted data should not be inserted.
- HTML should be escaped before inserting any untrusted data.
- The attribute should be escaped before inserting the untrusted data, etc.
Hence, Cheat Sheet may be very helpful in preventing this type of attacks.
Conclusion
While testing, it is highly recommended to evaluate the risks that bring possible XSS attacks. XSS attack can affect web applications, that seem to be secure as well.
It is considered to be one of the most harmful and risky attacks. Hence, we should not forget this type of testing. While performing testing against XSS, it is important to have a good knowledge about this attack. And this is the basis to analyze the testing results correctly and choose the appropriate testing tools.
