How to identify Cross Site Scripting (XSS) Vulnerabilities threat
July 20, 2014
Do you know that almost every website or application has some security flaws which make them vulnerable to the possibility of being hacked or attacked. There are certain group, which are known as black hat hackers, take advantage of this security flaws and try to access or steal sensitive data, redirecting file and even shut down that application and lot more. There are various such types of vulnerabilities and one of them is Cross Site Scripting or alias ‘XSS’.
According to a recent survey conducted by White Hat Security, Cross Site Scripting remain top in the virus list in 2014. It happens when a web application accumulates data from a user which might be malicious, and then stores input in a data store for later use. Entered input that is stored is not correctly separated. Malicious data will be displayed to be part of the website and run within the user’s browser under the web application.
What attackers can do with this type of vulnerability?
- Hack other browsers
- Steal sensitive data viewed by application users
- Fake damaging the appearance of the application
- Direct delivery of browser-based work excessively hard and lots more.
Stored XSS does not need a malicious link to be exploited. A successful exploitation occurs when a user visits a page with a stored XSS. The following phases relate to a normal stored XSS attack scenario:
- Attacker stores vicious code into the vulnerable page
- User authenticates in the application
- User visits vulnerable page
- Vicious code is executed by the user’s browser
See Also: Serious threats from Heartbleed Bug
As a Web tester, I know that the technological foundation of Web applications consists of HTTP and HTML. The HTTP protocol is the delivery transport for HTML, the code used to layout and form the Web page.
Cross Site Scripting (XSS) vulnerabilities exist when a Web application that accepts user input through HTTP requests such as a GET or a POST and then redirected to display inputs somewhere in the output HTML code.
System testing or Black Box testing to identify stored XSS vulnerabilities
The first step is to identify all points where user input is stored into the back-end and then displayed by the application. User input can be found in the following sections:
- User Profile page: The application allows the user to edit or change profile details such as first name, last name, picture & address, etc.
- Online Shopping: The application allows the user to store items into the shopping cart which can then be reviewed later
- File Management System: Applications where there is a option to upload files
- Application settings/preferences: Options to set or allow users profile
- Blog: If the blog gives permission to user for comments in the application
- Log: Stores some users input into logs of the application
HTML code Analyze
Example: Email id stored data in index1.php
In this case, the tester needs to find a way to inject code outside the <input> tag as below:
[sourcecode language=”html”]<input class="inputbox" type=text" name="email" size="40" value="email@example.com"> MALICIOUS CODE <!-/>[/sourcecode]
Testing for Stored XSS
This involves testing the input validation and filtering controls of the application. Basic injection examples in this case:
The HTML code following the injection:
[sourcecode language=”html”]<strong><input class="inputbox" type="text" name="email" size="40" value="firstname.lastname@example.org"><script>alert(document.cookie)</script></strong>[/sourcecode]
The input is stored and the XSS payload is executed by the browser when reloading the page. If the input is escaped by the application, testers should test the application for XSS filters. For instance, if the string “SCRIPT” is replaced by a space or by a NULL character then this could be a potential sign of XSS filtering in action. Many techniques exist in order to evade input filters.
Hope you liked it. Go ahead and post your comments what you think about this?