Thursday, April 16, 2015

CSPF supports the IronWASP project with an INR 1,00,000 contribution

Cyber Security and Privacy Foundation (CSPF) has made a contribution of INR 1,00,000 to the IronWASP project. IronWASP is an open source project that is used by tens of thousands of people around the world. Some of the users contribute by providing feedback, reporting bugs and by spreading the word amongst their peers.

The project is financially supported only from my personal funds. Although a few interested parties wanted to support the project in the past, they wanted to ultimately kill off the open source scanner and turn it in to a commercial product. So I had turned them down but this is the first time we have received financial contribution from an external party that only wants to help the open source initiative. This is a very nice gesture, so a big thanks to J Prasanna of CSPF for doing this.

To keep up with the latest project updates please follow the IronWASP twitter account

Post by Lavakumar Kuppan
Founder, IronWASP Project

Monday, February 9, 2015

IronWASP 2015 with Dynamic JavaScript Vulnerability Analysis support

A new version of IronWASP (@ironwaspsec) is here with some important bug fixes and a brand new feature - JavaScript Tracing!

I spoke about this feature and the technique behind it at nullcon last week and here it is as promised!

Discovering vulnerabilities on the client-side is a tough task particularly because of the lack of tools that make this possible. Dominator Pro is perhaps the only effective tool for finding DOM XSS right now.

I had tried to address this problem through static analysis, the very first version of IronWASP came with a fancy debugger-style visual taint tracking system. I had even debated the merits of static analysis with Stefano. But the short comings of static analysis are far too important to ignore.

Just knowing that the keyword eval is present in a page is of very little practical use, unless we know if it actually gets called and if it does then what were the values of the arguments that were passed to it. This can only be achieved through dynamic analysis, so after working together with Nafeez we made this possible in IronWASP.

This feature is very easy to use, the new version has a separate tab named 'JavaScript Tracing', check the 'Enable JavaScript Tracing' box and IronWASP will start logging dynamic events from all pages proxied through it. The events that are currently being traced are:

1) eval method calls
2) setTimeout method calls
3) setInterval method calls
4) Function method calls
5) XMLHttpRequest open and send method calls
6) Addition of new HTML elements to the DOM
7) Addition or updation of attributes of an HTML element

These events are logged under the sections 'Native Method Calls', 'Dom Changes' and 'Ajax Calls'. In addition these events are also analyzed to see if any portion of the URL appears in the sensitive sections of these events. If a match is found then it is shown under the 'Observations' section, along with some basic suggestions on how you can test to see if the observation is actually a valid security problem.

I opened and searched for "ironwasp" after enabling JavaScript tracing and the tool captured:

23 calls to the eval method
737 instances where either a new node was added to the page or an element's attribute was modified
14 Ajax calls

And there were 3 instances where some part of the URL ended up in eval calls and in the new HTML elements that were added.

The image below shows the report corresponding to one of the observations.

This is version 1.0 of this feature. I have already got feedback for new additions from some of the wonderful people who attended my nullcon talk and also from Mario himself! I would be addressing these concerns in the future versions along with expanding the scope of the events we monitor. If you have any feedback that you think could help improve this feature then please do share them with me.

Happy JavaScript vulnerability hunting!

Please follow @ironwaspsec to keep track of all IronWASP related updates easily.

And now enjoy some pictures of mine taken during the talk. I now officially hold the record for the coolest shades worn by a speaker at nullcon, lets see if my record gets challenged next year ;)

Post by Lavakumar Kuppan

Thursday, November 27, 2014

Analysing, Testing and Fuzzing WebSocket Implementations with IronWASP

WebSockets is an HTML5 feature that is seeing some good adaptation in newer websites. It is an asynchronous persistent full-duplex communication system and therefore is completely different from HTTP and AJAX. In some sense testing applications using WebSockets is similar to testing thick-clients using their own custom protocols because each WebSocket implementation could be designed very differently from the other.

Given how complex and unique WebSocket implementations can be and how it is difficult to properly analyse and test them using existing tools, I have tried to take a stab at the problem.

I have added five new tools to IronWASP that are dedicated to WebSocket Security Testing:

1) WebSocket Message Analyzer
An utility to analyse complex WebSocket implementations in a simple way. Check out this report of of our WebSocket Demo Application.

2) Online Cross-Site WebSocket Hijacking Tester
An online tool to easily check for CSWSH issues. Check it out here.
To understand more about Cross-Site WebSocket Hijacking check out this post on NotSoSecure

3) WebSocket Client
Versatile WebSocket client that lets you send store and send multiple messages along with setting custom Origin and Cookie headers. Perfect for checking Cross-Site WebSocket Hijacking and other WebSocket issues.

4) WebSocket Scripting API for Python and Ruby
To automated checks and write custom fuzzers for WebSocket implementations. Generic fuzzers don't work for asynchronous protocols like WebSockets.
Check out these code samples on Gist:

5) WebSocket Demo App
A sample vulnerable application that is built to use WebSockets heavily. Good test bed to test and learn WebSocket security testing.

Do check out the post I have made on NotSoSecure for more information on WebSocket Security and for the need behind making these tools.

I demos most of these tools at the Ground Zero Security conference recently and also at null Bangalore.

Here are some videos where I have tired to show how these tools can be used to test WebSocket implementations:

Some screenshots of these tools:
Menu Option to launch two of the 5 messages
Results of the WebSocket Message Analyzer

Online Cross-Site WebSocket Hijacking Tester

CSWSH Tester in action

Testing with IronWASP's WebSocket Client

Scripting with WebSocket Testing API

The WebSocket Demo Application
All of these tools should make WebSocket Security Testing easier than it currently is. Hope you find these useful and if you find any of them lacking in any area then do drop a comment, I will try to address those needs.

Please follow the IronWASP twitter account for all project updates.

Post by Lavakumar Kuppan

Tuesday, July 29, 2014

Contexts and Cross-site Scripting - a brief intro

Yesterday Anant posted a question in the IronWASP Facebook group asking about the different potential contexts related to XSS to better understand how context specific filtering is done. It would be hard to post the response in a comment so I am turning it in to a blog post instead.

If you are the kind of person who likes reading code instead of text then download the source code of IronWASP and check out the CrossSiteScriptingCheck.cs file in the ActivePlugins directory, this post is based on the logic IronWASP uses for its XSS check.

If user controlled input appears in some part of a web page and if this behaviour leads to the security of the site getting compromised in someway then the page is said to be affected by Cross-site Scripting. A web page is nothing but just text, the browser however does not look at it as a single monolithic blob of text, instead different sections of the page could be interpreted differently by the browser as HTML, CSS or JavaScript.

Just like the word 'date' could mean a fruit, a point in time or a romantic meeting based on the context in which it appears, the impact that user input appearing in the page can have would depend on the context in which the browser tries to interpret the user input. I will try to list out the different contexts in which user input can occur in a web page.

1) Simple HTML Context

In the body of an existing HTML tag or at the start and end of the page outside of the <html> tag.

<some_html_tag> user_input </some_html_tag>

In this context you can enter any kind of valid HTML in the user input and it would immediately be rendered by the browser, its an executable context.

Eg: <img src=x onerror=alert(1)>

2) HTML Attribute Name Context

Inside the opening HTML tag, after tag name or after an attribute value.

<some_html_tag user_input some_attribute_name="some_attribute_value"/>

 In this context you can enter an event handler name and JavaScript code following an = symbol and we can have code execution, it can be considered to be an executable context.

Eg: onclick="alert(1)"

3) HTML Attribute Value Context
Inside the opening HTML tag, after an attribute name separated by an = symbol.
<some_html_tag some_attribute_name="user_input" />
<some_html_tag some_attribute_name='user_input' />
<some_html_tag some_attribute_name=user_input />
There are three variations of this context:
- Double quoted attribute
- Single quoted attribute
- Quote less attribute

Code execution in this context would depend on the type of attribute in which the input appears. There are different types of attributes:

a) Event attributes

These are attributes like onclick, onload etc and the values of these attributes are executed as JavaScript. So anything here is the same as JavaScript context.

b) URL attributes

These are attributes that take URL as a value, for example src attribute of different tags. Entering a JavaScript URL here could lead to JavaScript execution

Eg: javascript:some_javascript()

c) Special URL attributes

These are URL attributes where entering a regular URL can lead to security issues.
Some examples are:
<script src="user_input"
<iframe src="user_input"
<frame src="user_input"
<link href="user_input"
<object data="user_input"
<embed src="user_input"
<form action="user_input"
<button formaction="user_input"
<base href="user_input"
<a href="user_input"

Entering just an absolute http or https URL in these cases could affect the security of the website. In some cases if it is possible to upload user controlled data on to the server then even entering relative URLs here would lead to a problem. Some sites might strip off http:// and https:// from the values entered in these attributes to prevent absolute URLs from being entered but there are many ways in which an absolute URL can be specified.

d) META tag attributes

Meta tags like Charset can be influence how the contents of the page are interpreted by the browser. And then there is the http-equiv attribute, it can emulating the behaviour of HTTP response headers. Influencing the values of headers like Content-Type, Set-Cookie etc will have impact on the security of the page.

e) Normal attributes

If the input appears in a normal attribute value then this context must be escaped to lead to code execution. If the attribute is quoted then the corresponding quote must be used to escape the context. In case of unquoted attributes space or backslash should do the job. Once out of this context a new event handler can be added to lead to code execution.

" onclick=alert(1)
' onclick=alert(1)

4) HTML Comments Context

Inside the comments section of HTML

<!-- some_comment  user_input some_comment -->

This is a non-executable context and it is required to come out this context to execute code. Entering a --> would terminate this context and switch any subsequent text to HTML context.

Eg: --><img src=x onerror=alert(1)>

5) JavaScript Context

Inside the JavaScript code portions of the page.


This applies to the section enclosed by the SCRIPT tags, in event handler attributes values and in URLs preceding with javascript: .

Inside JavaScript user input could appear in the following contexts:
a) Code context
b) Single quoted string context
c) Double quoted string context
d) Single line comment context
e) Multi-line comment context
f) Strings being assigned to Executable Sinks

If user input is between SCRIPT tags then, no matter in which of the above contexts it appears you can switch to the HTML context simply by including a closing SCRIPT tag and then insert any HTML.

Eg: </script><img src=x onerror=alert(1)>

If you are not going to switch to HTML context then you have to tailor the input depending on the specific JavaScript context it appears in.

a) Code Context

function dev_func(input) {some_js_code}

This is an executable context, user input directly appears as an expression and you can directly enter JavaScript statements and they will be executed.

Eg: $.post("", {'cookie':document.cookie}, function(){})//

b) Single quoted string context

var some_variable='user_input';

This is a non-executable context and the user input must include a single quote at the beginning to switch out of the string context and enter the code context..

Eg: '; $.post("", {'cookie':document.cookie}, function(){})//

c) Double quoted string context

var some_variable="user_input";

This is a non-executable context and the user input must include a double quote at the beginning to switch out of the string context and enter the code context..

Eg: "; $.post("", {'cookie':document.cookie}, function(){})//

d) Single-line comment context


This is a non-executable context and the user input must include a new line character to terminate the single line comment context and switch to the code context..

Eg: \r\n$.post("", {'cookie':document.cookie}, function(){})//

e) Multi-line comment context


This is a non-executable context and the user input must include*/ to terminate the multi-line comment context and switch to the code context..

Eg: */$.post("", {'cookie':document.cookie}, function(){})//

f) Strings being assigned to Executable Sinks

These are single quoted or double quoted string contexts but the twist is that these strings are passed to a function or assigned to a property that would treat this string as executable code.

Some examples are:
location = "user_input";
setTimeout(1000, "user_input");
x.innerHTML = "user_input";

For more sinks refer the DOM XSS wiki.

This should be treated similar to Code context.

6) VB Script Context

This is very rare these days but still there might be that odd site that uses VBScript.

<script language="vbscript" type="text/vbscript">

Like JavaScript, you could switch out to HTML context with the </SCRIPT> tag.

Inside VBScript user input could appear in the following contexts:
a) Code context
b) Single-line comment
c) Double quoted string context
d) Strings being assigned to Executable Sinks

a) Code Context
Similar to its JavaScript equivalent, you can directly enter VBScript

b) Single-line comment
VBScript only has single-line comments and similar to its JavaScript equivalent entering a new line character will terminate the comment context and switch to code context

c) Double quoted string
Similar to its JavaScript equivalent

d) Strings being assigned to Executable Sinks
Similar to its JavaScript equivalent

7) CSS Context

Inside the CSS code portions of the page.


This applies to the section enclosed by the STYLE tags and in style attributes values.

Injecting CSS in to a page itself could have some kind of impact of the page. For example, by changing the location, visibility, size and z-index of the elements in a page it might be possible to make the user perform an action different from what they think they are doing.

But the more interesting aspect is in how JavaScript can be executed from within CSS. Though, not possible in modern browsers older browser did support JavaScript execution in two ways.

i. expression property
expression is a Internet Explorer only feature that allows execution of JavaScript embedding inside CSS.

  property_name: expression(some_javascript);

ii. JavaScript URLs
Some CSS properties like the background-image property take an URL as their value. In older browsers, entering a JavaScript URL here would result in JavaScript code being executed.

background-image: javascript:some_javascript()

Inside CSS, user input could appear in the following contexts:
a) Statement context
b) Single quoted/Double quoted string context
c) Multi-line comment context
d) Strings being assigned to Executable Sinks

Similar to the SCRIPT tag, if user input is between STYLE tags then you can switch to the HTML context simply by including a closing STYLE tag and then insert any HTML.

Eg: </style><img src=x onerror=alert(1)>

If you are not going to switch to HTML context then you have to tailor the input depending on the specific CSS context it appears in.

a) Statement Context

In this context you can directly start including CSS to modify the page for a social engineering attack or make use of expression property or the JavaScript URL method to inject JavaScript code.

b) Single quoted/Double quoted string context

Including a single or double quote at the start of the input would terminate the string context and switch to statement context.

c) Multi-line comment context

Similar to JavaScript multi-line comment, entering */ would terminate the comment context and switch to statement context.

d) Strings being assigned to Executable Sinks

This is a single-quoted are double-quoted string that is either passed to the expression property or a property that takes an URL like background-image. In both cases the data inside the string context can be interpreted as JavaScript code by the browser.

Though I have mentioned the standard ways to escape out of the different contexts, these are by no means the only ways. There are plenty of browser quirks that allow escaping out of contexts in strange ways. To find out about them I would recommend you get the Web Application Obfuscation book and also refer the HTML5 Security Cheatsheet and the fuzz results of Shazzer.

There is a good chance you might already know about OWASP's XSS Prevention CheatSheet, you might also find this other XSS Protection Cheat Sheet to be useful.

Monday, April 14, 2014

IronWASP 2014 is finally here!

IronWASP 2014 is finally here and it is packed with features to help make your life easy.

Here's what is new:

1) Login recording
Now you can easily just record a login sequence and use it in vulnerability scans and other automated tests. See video tutorial.

2) Automatically testing for CSRF, Broken Authentication, Privilege Escalation and Hidden Parameters
Now IronWASP has a new section called Interactive Testing tools that let you automatically discover vulnerabilities that could only be discovered by manual testing.
See video tutorials for CSRF Tester, Broken Authentication Tester, Hidden Parameter Tester and Privilege Escalation Tester

3) Browser pre-configured for Manual Crawling
The most common problem with intercepting proxies is that you have to change your browser's proxy settings and import the tool's certificate as a trusted CA for SSL traffic. Even after doing this there is change that traffic from your regular browsing will get mixed with your test traffic. IronWASP solves all of these problems, it comes with a browser pre-configured to use IronWASP as proxy, it handles SSL certificate errors automatically (no need to import as CA) and since this is a separate browser it does not affect the regular browsing that you are doing in your other browser. See video.

4) DOM XSS Analyzer
If you understand what DOM XSS sources and sinks are and have the ability to understand and analyse JavaScript code then you will find this new utility really useful. It makes the process of discovering DOM XSS really easy for manual testers. See video tutorial.

5) XmlChor - XPATH Injection Exploitation tool
This version comes with a new Module called XmlChor written by Harshal Jamdade. This module can be used to automatically exploit XPATH Injection vulnerabilities and extract the backend XML file from the server. See video tutorial.

6) WiHawk - WiFi Router Vulnerability Scanner
There version has one more awesome module called WiHawk written by Anamika Singh. This module can be used to scan a range of IP addresses for WiFi routers that have default password and authentication bypass vulnerabilities. It also supports Shodan API to scan large number of devices on the internet. See video tutorial.

Also we have a new logo for IronWASP, thanks to Ranjeet Sengar.

There are a huge number of other additions that make the overall user experience better. I have made a lot of improvements to this version based on user feedback. So keep those feedback coming and the next version will be even better than this one!


Sunday, October 27, 2013

Solving Pentester Academy Web Application Challenge -1 in both Python and Ruby using IronWASP

Unless you have been living under a rock you would have heard about Pentester Academy, a SecurityTube initiative that promises to bring good quality and affordable online security training to everyone.

As part of their Web Application Security course, Vivek has put out a bunch of challenges where you can test your security and scripting skills.
Solving some of the challenges requires writing your own scripts and what better tool for scripting than IronWASP. So based on popular demand I am going to be making a series of blog posts where I will show how you can solve these challenges by writing Python or Ruby scripts.

There is also a video that briefly explains some of the things covered in this post.

Challenge -1:


Take a moment to check out this video containing challenge description.

The challenge itself is available here -
Difficulty Level: Beginner
Objective: Find out a valid username and password for the login page.
  1. The usernames could be or
  2. The password is 5 characters long and only consists of the characters x, y and z

To solve this challenge we have to do password cracking. We already know that the username can be either or
The password is some word between xxxxx and zzzzz. To find out which one it is we have to try logging in with every 5 letter combination between xxxxx and zzzzz and see which one succeeds. The password only consists of three different characters x,y,z and the password length is 5 characters so the total number of combinations is 3^5 = 243.

The flowchart for the approach is below:

First we try all password combinations for the username If that doesn't work then we redo the password cracking for the username
Now that we know what to do, let's create the script. When trying to create this script we are faced with three important questions.
  1. How to perform the login from the script with a specified username and password?
  2. How to come up with all combinations of password from xxxxx to zzzzz?
  3. After the login response is received, how to determine if the login was successful?
I will answer all three questions below and you will see how IronWASP makes this whole process so simple.

To test out some of the commands and API calls you can make use of the 'Interactive Shell' of IronWASP. Make sure you pick the language of your choice - Python or Ruby and you will get a Python or IRB shell.

How to perform the login from the script with a specified username and password?

Before we can do the login in the script first let us see how the browser performs the login. Open Google Chrome browser and visit
Now open IronWASP, go to the 'Proxy' section click on the checkbox named 'Set as System Proxy'.

Now IronWASP can capture all traffic from the opened Google Chrome browser. In your browser enter some value for username and password in to the login page and click on 'Sign in', you must see the invalid login message from the server. That's ok, we are only interested in knowing how the login request looks. If you go to the 'Log' section in IronWASP you must be able to identify the login request in there, it will have the value of the username and password you entered. Make a note of the ID number of that particular log.

To send this request from our script we can simply pick it from the logs using IronWASP's API by providing the corresponding log ID.
r = Request.FromProxyLog(1)
r = Request.from_proxy_log(1)
In my case the ID of the login request in the logs was 1, it could be something else in your case, use the corresponding value.

Once we create the request we must set the username and password values as per our requirement. Before we do that we must find out where the username and password values are stored in the Request. If you look closely you will find that the query part of the request has these values. The name of the query parameter carrying the username is 'email' and the name of the query parameter carrying the password is 'password'.

Now that we know this we can easily update these values from within our script.
r.Query.Set("password", "xxxxx")
r.query.set("password", "xxxxx")
After creating and modifying the request we now have to send this request and get the response. We do this like this:
res = r.Send()
res = r.send_req

How to come up with all combinations of password from xxxxx to zzzzz?

The latest version of IronWASP makes this step extremely easy, a new class called BruteForcer has been added to the API which can create the password combinations for you.
All that you have to do is mention what characters the password can contain, the minimum length the password can have and the maximum length. With this information BruteForcer will automatically generate all combinations for the given input.
If you wanted to get all the 4-8 letter lower-case alphabet based password combinations then this is how you do it.
br = BruteForcer("abcdefghijklmnopqrstuvwxyz", 4, 8)
print "Total combinations count is " + str(br.TotalCount)
while br.HasMore():
  print br.GetNext()
br ="abcdefghijklmnopqrstuvwxyz", 4, 8)
puts "Total combinations count is " + br.total_count.to_s
while br.has_more
  puts br.get_next
In this case our character set would be x, y and z and both the minimum and maximum length will be 5. So the input we would provide would be:
BruteForcer("xyz", 5, 5)
Ruby:"xyz", 5, 5)

After the login response is received, how to determine if the login was successful?

This one is a little tricky, we don't know how the response would look if the login was successful but we do know how the response looks for an invalid login. The important glaring part of this the error message 'Failed! Please try again!'. If this error message does not appear in the response then it would be safe to assume that the login was successful.
So we have to look for this message in the body of the response that we get. Let's first check how this message appears in the source code of the page, we have to look for it in the exact same form.
And this is how this check can be done from the script.
if res.BodyString.count("Failed! Please try again!") == 0:
  print "Login is successful!!!"
if not res.body_string.include? "Failed! Please try again!"
  puts "Login is successful!!!"
Now that we have all the important parts covered let's put it all together and create the script.
Below you can see the complete Python and Ruby scripts for this challenge.


 Use the Multi-line Shell of IronWASP to execute these scripts. Make sure you have selected the appropriate language then paste or type your script in the text area and hit the 'Execute Multiline Script' button.
Once the script starts executing you must see the list of each password being tried, printed out in the console output area. 
If the script manages to crack the password then you will see the value of the password printed out like this.
If the password cracking does not succeed for then update the script to try password cracking for Let's see if you can find out the valid username and password.
Good luck!! If you have any questions then you can send me an email or catch me on twitter.

Friday, October 25, 2013

Better support for importing Burp Suite Log and Export files in IronWASP v0.9.7.2

IronWASP v0.9.7.2 is now available for download. Users of older versions should get an update prompt when using IronWASP.

With this release you get:
1) A better JSON parser
2) Better support for handling binary data in JSON, XML and Multipart
3) A faster and more responsive rendering of response body when the 'Render' link is clicked

The most important new addition however is the support for importing Burp Suite export files.
IronWASP has always had support to import Burp Suite log files, the image below shows how logging can be turned on in Burp Suite.

But with the new version import the Burp Suite export files as well.
You can export Burp Suite logs to a XML file using the option shown in the image below

Once exported you can make use of the import feature of IronWASP to load the XML file.

But what's the benefit?

But why would you want to import Burp Suite files in to IronWASP. I will list some of the benefits below:

1) Passive Vulnerability Analysis

As soon as you import the logs IronWASP performs passive vulnerability analysis and reports a bunch of issues

2) Automated Vulnerability Scanning

IronWASP also builds a sitemap from the import log. You can right click on the site map and scan all or some of the items there.

Or you can pick a single request and perform a vulnerability scan. The nice thing about IronWASP is you can get very precise with your scans. If you fancy then you can just scan one parameter from one request for a specific vulnerability check.

The scan creation wizard gives options to scan for most of the well known vulnerabilities. After the scan is done you can even perform Anomaly based vulnerability detection on the scan logs.

3) Searching and analysing imported logs

You can perform a keyword and filter based search of the logs. From the search results you can pick a bunch of logs and use IronWASP's 'Parameter Manipulation' feature to automatically test for CSRF, Hidden Parameter Guessing, Privilege Escalation and other access control issues.

4) Scripting

IronWASP's USP is its unrivalled scripting integration. You can access and analyse the import logs in both Ruby and Python.

Want to perform a custom passive analysis of the traffic or write your own fuzzer to fuzz some of the requests in the logs? feel free. Open the 'Script Creation Assistant' and you will be on your own in no time.

5) Reporting

IronWASP comes with a reporting engine that creates reports in both HTML and RTF forms. You easily generate reports of the newly identified vulnerabilities.

5) Reloading the logs

Once you import the Burp Suite logs a new IronWASP project is created from it. So if you are closing IronWASP then the next day you can reload the project file and continue from the exact place you left off. All logs and vulnerabilities are stored in the project files and are completely reloaded.

This new version also has a new feature added to the Scripting API called 'BruteForcer'. The next blog post will show how this feature can be used.