Cross-Site Scripting (XSS) remains one of the most common security vulnerabilities currently found in web-applications. This article provides insight into how to test your applications for Cross-Site Scripting (XSS) defects using both manual and automated means.
For an introductory description of Cross-Site Scripting (XSS) see the article entitled: “What is Cross-Site Scripting ?“.
Automated Tools for Cross-Site Scripting (XSS) Detection
The complexity of today’s websites and web-applications practically mandates the use of security testing tools.
There are a number of automated tools, including some Browser Plugins that can be useful in detecting Cross-Site Scripting (XSS) vulnerabilities. While a survey of these are beyond the scope of this article, a word of caution is in order. The use of automated tools can lend a false sense of security to developers and testers, since the tools can be blind to certain variations of Cross-Site Scripting (XSS) defects.
Generally speaking, Cross-Site Scripting (XSS) detection tools identify input parameters whose values are allowed to contain meta-characters meaningful to HTML (e.g. <, >, ‘, “, !, -, etc.) that are reflected back unmodifed in a response.
For example, some tools operate by parsing pages for forms and generating malicious payloads for each field discovered, submitting each form, and then scanning the immediate web-application response for unmodified inputs. Although this approach CAN detect Reflected Cross-Site Scripting (XSS) problems, it can miss those inputs that are reflected in subsequent responses.
Another limitation of tools is that they may only hint at the problem, rather than providing you with an exploitable example. A tool may identify an parameter that gets reflected back unmodified, but is not correctly crafted to break the content/code barrier. It may turn out that with a little syntax tweaking, it is exploitable. It may turn out that it is not. In other words, there may be some manual work required to cull out false-positives from the results of automated Cross-Site Scripting (XSS) scans.
Despite having some limitations, automated tools are indispensable when searching for Cross-Site Scripting (XSS) vulnerabilities. Tools such as Burp Suite and OWASP ZAP provide straightforward means to select target parameters and test them repeatedly with sets of XSS sentinel strings, including those of your own design.
Manual Detection of Cross-Site Scripting (XSS) Vulnerabilities
Manual testing should augment automated testing for the reasons cited above. Manual testing may involve entering classic “sentinel” XSS inputs (see: the OWASP XSS Filter Evasion Cheatsheet), such as the following (single) input:
‘;alert(String.fromCharCode(88,83,83))//’;alert(String.fromCharCode(88,83,83))//”;
alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//–
></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
into form fields and parameter values in HTTP Requests and look for resulting pop-ups in subsequent responses. The example above is a bit complex because it combines several variations of attempts to break the content/code barrier for multiple contexts (HTML, Comment, JavaScript, etc.) using the same string.
Of course the key to successful manual discovery is to understand exactly how reflected inputs appear in the response, and how to potentially exploit that specific situation. Some trial and error is typically required.
Combining Automated and Manual testing is the ultimate power-combination, because it scales up your ability to test an applications parameters with entire collections of XSS sentinel strings. This combined approach also allows you to rapidly identify anomalous responses that may be indicative of a potentially successful exploit.
For additional information on detecting Cross-Site Scripting (XSS) vulnerabilities, we recommend the OWASP article on Testing for Cross site Scripting.
To understand how to prevent Cross-Site Scripting (XSS), see the article entitled: “How to Prevent Cross-Site Scripting (XSS)“.
Sources of Untrusted Input
It is important that you do not overlook potential sources of untrusted input, as doing so may mean you overlook a potential problem. Keep in mind that:
- All input sources must be examined, including:
- Query parameters within the submitted URL and any other URLs coming in as data
- Post parameters in they body of the request
- HTTP Headers
- Structured data formats such as JSON, XML, etc.
- Encoded data
- AJAX submissions are not immune from XSS vulnerabilities, depending on the circumstances
- Web Services may be an “enabling technology” when it comes to XSS vulnerabilities, since they are largely designed without consideration of how information is displayed
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.