Month: July 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

Input Forms
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
Input stored by the application is normally used in HTML tags, but it can also be found as part of JavaScript content. At this stage, it is to understand if input is stored and how it is positioned in the context of the page.The pen-tester should also investigate differently through which the application receives and stores users input.
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="johndoe@gmail.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:

[sourcecode language=”plain”]johndoe@gmail.com"><img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="&lt;script&gt;" title="&lt;script&gt;" />
johndoe@gmail.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E[/sourcecode]

Ensure the input is submitted through the application. This normally involves disabling JavaScript if client-side security controls are implemented or modifying the HTTP request with a web proxy such as Web Scarab. It is also important to test the same injection with both HTTP GET and POST requests. The above injection results in a popup window containing the cookie values.

The HTML code following the injection:

[sourcecode language=”html”]<strong><input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="&lt;script&gt;" title="&lt;script&gt;" /></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.

If you find the above process is little bit complicated or you need some sort of support then don’t worry you can get a free testing report through our accomplished QA engineers.

Hope you liked it. Go ahead and post your comments what you think about this?