Parsons Software Security Consulting Blog

How to automate XSS with Dinis Cruz 02

leave a comment »

In today’s post we are going to discuss the steps to automate a XSS scripting attack using Dinis Cruz’s 02.   Dinis is a really smart guy and good friend of mine.   I like the work that he is doing with O2.   The tool we are going to use allows you to automate custom XSS exploits.   The value of this tool is that you don’t have to go to RSNAKE’s XSS cheat sheet website everytime you want to show XSS.

Below are some Cross Site Scripting vulnerabilities found on IBM’s demo website with IBM Appscan.

It is good that the tool found these vulnerabilities but now you have to prove whether or not they are false positives.   This can help with Dinis’s O2 tool.   We are going to write a custom 02 script that we can later on recreate and give to developers or system administrators as unit tests.   But for now we are just going to use Snagit and describe it in a detailed report.

Above is the standard XSS that IBM appscan created.  If you want to be worth your salt as a pen tester do not give this to your client.

For this usecase we are going to exploit the lang variable.

Vulnerability Description

Multiple instances of Cross-Site Scripting were identified. This vulnerability could allow an attacker to craft a malicious link or get malicious code inserted in to a user’s browser. Normally this is used to steal session identifiers or credentials allowing them to compromise the application’s data. This vulnerability could also be used to insert malicious content in to the user’s browser potentially compromising their system. The recommendation for this issue should be applied anywhere where the application accepts data from a user and it gets echoed back to the screen. A list of some of the identified URLs with XSS issues are listed in Appendix A. Some of the URLs may have multiple variables that are vulnerable.

The following shows a XSS vulnerability and a popup of document.cookie.

Vulnerability Recommendation

Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. Always use as strict a pattern as you can possibly allow. Encoding of output ensures that any scriptable content is properly encoded for HTML before being sent to the client.

Be sure to consider all paths that user input takes through your application. For instance, if data is entered by the user, stored in a database, and then redisplayed later, you must make sure it is properly encoded each time it is retrieved. If you must allow free-format text input, such as in a message board, and you wish to allow some HTML formatting to be used, you can handle this safely by explicitly allowing only a small list of safe tags.

Secure coding practices, sanitization of user input, and properly encoding output should be used. The application should only accept content for which it is expecting for that particular variable. If a variable is only needing to accept alphabetic characters then it should only allow a-z and other characters should be denied. Encoding of the output ensure that any scriptable content is properly encoded for HTML before being sent to the client. This code would properly encode items such as <, >, \, \\, and & with their proper HTML equivalents such as &lt; &gt; &quot; etc.

Written by mparsons1980

November 23, 2010 at 8:19 pm

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: