Testing XSS vulnerabilities on web applications

How to test XSS vulnerabilities on web applications

The Cross-site Scripting (XSS) vulnerability is real and dangerous, it’s no longer a controversial issue. Let’s take a look at some of the XSS vulnerabilities as well as how dangerous it is and share with us some of the ideas of manual testing as well as the use of automated testing tools. Cross-site scripting is a common vulnerability in web applications. To exploit a Cross-site Scripting (XSS) vulnerability, hackers insert malicious code through scripts to execute them on the client side. Typically, Cross-site Scripting attacks are used to bypass access controls and impersonate users. XSS attacks involve three parties:
  • The attacker
  •  Victims
  •  A malicious website that an attacker exploits to attack a victim
On three sides, the victim is the only one who actually runs the attacker’s code. Website is merely a means of attack and is usually not affected. An XSS attack can be done in many ways. For example, an attacker sends a malicious user via email, IM, or some other means. When the victim opens the URL in a web browser, the website displays the page and the script will run on their computer.

What is the XSS vulnerability?

As a developer/web tester, you know that the technology platform of web applications includes HTTP and HTML. The HTTP protocol is the delivery method for HTML – the code used to represent and create the website. XSS vulnerabilities exist when a web application accepts user input via HTTP requests such as GET or POST and then re-displays the input data somewhere in the output HTML code. Here is a simple example:
  1. With the Web request as follows:
GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title
  1. The HTML returned by the server after the execution of this request includes:
<h1> Section Title </ h1>
You can see that the input of the user is passed to the query string parameter “title” which can be placed in a string variable and inserted by the web application into the <h1> tag. By providing input, the attacker controls HTML.
  1. If the website does not filter input on the input server (because client-side controllers can always be ignored), the attacker may abuse this in several ways:
An attacker can inject code by exiting the <h1> tag:
http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title </ h1> <script> alert ('XSS% 20attack') </ script>
Output the HTML from this final request as follows:
<h1> Section Title </ h1> <script> alert ('XSS attack') </ script>
Even with the simplest example above, an attacker could do a lot of things with that link. Take a look at the underlying threats and then move on to some more advanced testing methods.

How serious is the XSS vulnerability?

Attackers can use XSS vulnerabilities to steal cookies, take over accounts, perform ActiveX controls, execute Flash content, force you to download software, and have some action on your hard drive and data. All this can happen simply by prompting you to click on some URL. How often do you click on a URL in an email that you trust a certain time through the message board or newsgroup you use? Phishing attacks often exploit the XSS vulnerability to legitimate websites. You’ve seen this a lot, such as an email from the bank in your inbox, letting you know that some changes have been made to your account and entice you to click. some links. If you look more closely at the URL, it may have exploited a flaw in the bank’s website and looks like http://mybank.com/somepage?redirect= <script> alert (‘XSS’) </ script>, where the “redirect” parameter has been exploited to perform the attack. If the attacker is really smart, they can execute an XSS attack targeted to the administrator, perhaps by sending a message titled “Help! This website URL continues to bug me!”. After the administrator opens the URL, the attacker can cause a lot of damage such as stealing their information and appropriating administrator privileges. So we understand the danger that XSS has – attacking users, attacking administrators, bad PR for companies… Now let’s take a closer look at the main point of the article – test your website on these issues.

How to test XSS vulnerabilities?

A complete security assessment not only requires XSS vulnerabilities; it also includes overall threat modeling, memory leak detection, information disclosure, error handling, SQL injection, authentication, and authentication errors. The good news is that when you check for this error you can detect other errors as well. For example, while testing the XSS vulnerability, you will often spot processing errors and information exposure problems.

1. Manual testing

If you are a developer with web programming expertise, you can manually test the XSS vulnerability on your application by following these steps:
Preparation tools for testing
Tools needed for manual testing include:
  • Paros proxy (http://www.parosproxy.org) to block HTTP traffic
  • Fiddler (http://www.fiddlertool.com/fiddler) to block HTTP traffic
  • Burp proxy (http://www.portswigger.net/proxy/)
  • TamperIE (http://www.bayden.com/dl/TamperIESetup.exe) to modify GET and POST
We have listed at least three web proxies here. You can also check out some other proxies because each proxy has its own characteristics. The problem is that you will need to block the HTTP requests of the web browser before they are sent, and then modify them to insert the XSS test. Each of these tools will do a job, and some will show you the HTML source code returned if you choose to intercept the server response. Preventing customers’ GET and POST requests is extremely important. This will allow you to bypass any type of client-side Javascript input validation code. One note for all web developers is that the client side security controls are really worthless. Confirmation must be made on the server.
Make a sitemap including its functions
Create some simple data flow diagrams describing the pages on the website and their purpose. You should do this before having a few meetings about the threats to the developers and project managers. Use that time to learn about the application as much as possible. Does this website offer web services? Include information such as authentication template, message board, user settings page? Be sure to list all pages.
Define and list the input provided by the user
This is the next step to make your sitemap more detailed. You should create a spreadsheet to do this. For each page, list all query string parameters, cookie values, custom HTTP headers, POST data values, and other input types provided by the user. Be sure to look for web services as well as similar SOAP requirements and identify all the fields that allow the user to enter. List all input parameters separately because you will need to test them independently of the other parameters. This is probably the most important step! Refer to the spreadsheet below to see the parameters in the sample page listed in groups. Query string values like forwardURL and lang. Value POST data such as name, password, msgBody, msgTitle, and even some cookie values. The process of checking these values is very important but they are very interesting. Testing XSS vulnerabilities on web applications
Think about it and list your test cases
Take a look at the above spreadsheet, which outlines the different ways in which to test the XSS vulnerability. In the spreadsheet, it lists each page with the values it allows and each type of check for each value. This is just an example, you can completely create a separate test method.
Start experimenting and pay attention to the output
The most important part of finding a loophole is not whether you find it, but whether you really know what’s going on. With XSS, just look at the HTML output and find its input. Is it in an HREF or IFRAME tag? Or does it have a CLSID or IMG SRC? What about PARAM NAME of some Flash content? If you understand exactly what the input is doing, you will be able to adjust your experiment to determine the problem. That means you need to append a closing “>” bracket to get rid of the tag, or add “” quotes to close the inside of the tag. Or you may need URLs or HTML encoded characters, such as by passing a “” quotation mark “” to% 22 or “.
What to do when the test fails?
It’s easy to test – <script> alert (‘hi’) </ script> does not bring the alert you expect. Talk to the developers if possible. Maybe they are filtering input for symbols like <>, ” or [] or they’re filtering from “script”. Again, study how the input is generating the output and how exactly each value (query string, cookie, POST data) is doing. A query string value like “pageId = 10” can never even generate an output, so it may be able to waste your test time. Sometimes just try to inject single characters like <>, “”, [] to see how the application is filtering those characters. Then you will know the level of filtering that you are processing. You can adjust the tests to encode those characters and try again or find other ways to inject.
Change test cases
Finding out how input values to HTML output pages are extremely important. If this does not happen, do not waste your time testing. If so, investigate where they are occurring because you will need to change your experiment accordingly. Here are some variants to determine the acceptable parameters and display the code:
> ''> <Script> alert ('XSS') </ script>
>% 22% 27> <img% 20src% 3d% 22javascript: alert (% 27XSS% 27)% 22>
>% 26% 23x6a;% 26% 23 × 61;% 26% 23 × 76;% 26% 23 × 61;% 26% 23 × 73;% 26% 23 × 63; % 26% 23 × 72;% 26% 23 × 69;% 26% 23 × 70;% 26% 23 × 74;% 26% 23x3a; alert (% 26quot; XSS% 26quot;)>
AK% 22% 20style% 3D% 22background: url (javascript: alert (% 27XSS% 27))% 22% 20OS% 22
% 22% 2Balert (% 27XSS% 27)% 2B% 22
<table background = "javascript: alert (([code])"> </ table>
<object type = text / html data = "javascript: alert (([code]);"> </ object>
<body onload = "javascript: alert (([code])"> </ body>
There are many variations to try. It is important to understand how the input is being processed and displayed on the output page.

2. Automated testing

A typical security vulnerability scanner will connect to the web application through the web interface, so that potential vulnerabilities and weaknesses of the web are discovered. This tool will not access the source code but only perform functional testing to find out the vulnerabilities. There are many web-based vulnerability scanning tools available today that can be used for free or for a fee. Below, we will list some of the leading web application vulnerability scanner tools that can help you evaluate your web application to eliminate security risks.
CyStack Platform – A Web Security Platform
Testing XSS vulnerabilities on web applications CyStack Platform includes 04 apps that provide security features for your website including: continuous security monitoring tools, web application firewalls, and malicious code tracking. 1. CyStack Scanning: Automatically detect and detect vulnerabilities CyStack’s CyStack Scanning App analyzes and detects more than 200 malicious Web-based vulnerabilities based on the OWASP 4.0 security standard. Apps will be updated daily by experts. 2. CyStack Monitoring: Early detection of problems on the website This application allows administrators to monitor and monitor their website 24/7. Whenever security issues, websites issues or cyber attacks occur … CyStack will send an early warning to administrators 24/7 via email and mobile app. 3. CyStack Protecting: A Web application Firewall helps block attacks from hackers and malicious code CyStack Protecting is a network capable of analyzing and preventing network attacks on websites by analyzing and disarming HTTP / s requests. Prevent network attacks, bad requests before they can penetrate the website. 4. CyStack Responding: Scan, detect and clean malicious code for websites CyStack Responding is an Antivirus for websites, portals/websites that allow administrators to scan, detect and clean malicious code that is already being spread to the site automatically. > Start your 14-day trial at here
Burp Suite Free software
Burp Suite is a set of vulnerability scanning tools for web applications. Users can experience a free version with limited or paid features to use the commercial version with maximum features. Burp Suite is an integrated platform for security testing of web applications. Diverse tools work perfectly together to support the entire testing process, from initial mapping to finding and exploiting vulnerabilities.
Designed to support both the detection and exploitation of vulnerabilities, the goal of Netsparker is to give users the most accurate results. To ensure the authenticity of the results, this tool only reports on vulnerabilities that have been identified after successful exploitation or testing. Netsparker will detect and report vulnerabilities such as SQL Injection and Cross-site Scripting (XSS) in all types of web applications, regardless of the platform and technology the web is built on. The Netsparker community version is provided free of charge to the Windows platform; It can run on Windows XP, 7, Vista, 2003 and 2008. You do not need any security expert to train, or a long tutorial to understand. You can start using Netsparker always because it is GUI and easy to use.
The W3af (Web application Attack and Audit Framework) is an open source web scanner that provides information about security vulnerabilities and assists in penetration testing efforts. This Web scanner provides a tool for scanning and exploiting vulnerabilities for web applications. W3af is written in Python and is available for many other popular operating systems such as Microsoft Windows, Linux, Mac OS X, FreeBSD, and OpenBSD. The W3af is divided into two main parts, namely core, and plug-ins. The scanner identifies most of the vulnerabilities in web applications using more than 130 plug-ins. Core integrates with processes and offers plug-in-based features, from which to identify vulnerabilities and exploit them. The plug-ins connect and share information with one another using a knowledge base. This is just a short list of the best security vulnerability scanning tools you can use to evaluate web applications for vulnerabilities. However, there are many other tools, and the use of security vulnerability scanning tools depends on the nature of the web application. In addition, the use of a web scanner to evaluate web applications is essential, as hackers’ techniques and techniques are becoming increasingly unhealthy and difficult to grasp.


Testing for XSS is often just a small part of a complete web application security test, but it ensures that this test is thoroughly implemented. After doing this for many years, we emphasize that the use of a spreadsheet or a document to store all the pages on the website, along with all input values per page accept cookies, POST data, SOAP) is an important step before you start testing. Equally important is to follow the input and understand how it is rendered on the output HTML page. If you know how the application is user input, you will accomplish this task more quickly. Do not waste time testing the inputs that do not display the output. Discuss with developers and developers about the threat model before you start.