IronWASP Series Part – 1

March 15, 2013, by | Start Discussion

Hello there, I am Lava, the author of IronWASP. This article is the first in the series of articles that I will be doing on IronWASP. In this article I will cover the introduction to IronWASP and explain how you can scan your websites for security vulnerabilities using it. In the future articles of this series we will look at how you can manually test your site and identify vulnerabilities, how you can use scripting and automate testing and finally we will see how you can extend IronWASP and create your own tools using it.

Before I start talking about what IronWASP is and what it can do, it is important do understand why it was written. I have spent over 6 years of my career in Penetration testing and most of that time was focussed on Web Application Penetration tests. During this time there were a handful of very good tools available for web application security scanning and testing, both commercial and open source.

But these tools were missing some critical functionality.

  1. I was not able to create very specific scan jobs. For example if I only wanted to the scan the search query parameter for Cross-site Scripting vulnerability then it was not possible in most cases. The existing scanners would only let me scan an entire site or specific urls.
  2. When the scanners performed a scan, I was very interested in knowing what they were doing. As a penetration tester I want to know what payloads were sent to the server, why these payloads are sent and how the server responded to them and how the scanner interprets these responses. All available scanners were doing their best to hide this information from the user.
  3. I wanted a scanner where I could not just look at the logic of the security checks but also edit and add new ones based on my requirements. Ideally I should be able to do this in the two most widely known scripting languages in the Penetration testing community – Python and Ruby
  4. I wanted first class support for scripting, with APIs designed specifically for security testing. As a penetration tester I had been using scripting for writing exploits and automating testing but for web related tasks the code was needlessly long and complex. If I wanted to write a password cracker for a website that I am testing then ideally it should not be more than a 6 line long simple script.

In short I wanted a tool that had the ease of use of a commercial scanner plus the manual testing capabilities of BurpSuite plus the automated scanning and scripting ability of W3AF plus a host of other features that none of them had. After a lot of thinking and brainstorming about the problem, IronWASP was born.

One year after its first public release the current version of IronWASP has come very close to the original vision I had for the ultimate web application security testing tool.

What is IronWASP ?

IronWASP is an open source advanced web application security testing platform that can:

  1. Automatically scan web applications for vulnerabilities
  2. Help with manual testing of web applications
  3. Help with test automation with its strong scripting support
  4. Help create your own web security tools in the easiest and quickest way

Shay Chen (@sectooladdict) of performed a comprehensive comparison study of all Web Security Scanners and based on this study IronWASP was listed as the #2 Open Source Web Security Scanner through the overall points earned.

At the moment IronWASP can scan a website for the following vulnerabilities:
Through Active Scanning:

  1. SQL Injection
  2. Cross-site Scripting
  3. Command Injection
  4. Header Injection
  5. Code Injection
  6. LDAP Injection
  7. XPATH Injection
  8. Local File Include
  9. Open Redirect
  10. Remote File Include

Through Parameter Manipulation Scanning (with user assistance):

  1. CSRF
  2. Broken Access Control
  3. Privilege Escalation
  4. Hidden Parameter Guessing

Through Passive Scanning:

  1. Use of HTTP Basic Authentication
  2. Cookies without Secure and Http-Only Flag
  3. Cookies containing Sensitive Information
  4. Insecurely Configured CrossDomain.xml file
  5. Directory Listing Turned On
  6. Potential Open Redirect Candidates
  7. DOM XSS Sources and Sinks in the Page
  8. Script, IFRAME and CSS Loaded from External Domains
  9. Script, IFRAME and CSS Loaded over HTTP in an HTTPS Page
  10. Script, IFRAME and CSS Loaded over HTTPS in an HTTP Page
  11. HTML Form Contents Submitted to External Domains
  12. HTML Form Contents From HTTPS Page Submitted to HTTP Page
  13. HTML Form Contents From HTTP Page Submitted to HTTPS Page
  14. HTML Form with Password Field Loaded Over HTTP
  15. Password Sent in URL
  16. Potential Session Fixation Candidates
  17. Vulnerable Version of Web Server
  18. Web Server Banner Grabbing
  19. X-Header Analysis

How to perform Automated Scanning with IronWASP

IronWASP has a flexible scanning engine that has five different scanning modes. No matter what your scanning requirement is, you will be able to find a mode that fulfils it.

When scanning certain sections of the website CSRF tokens must be updated or authentication must be performed before the scan. Such site specific scan customization can be handled by IronWASP easily using a feature known as Session Plugin. We will be discussing Session Plugins in one of the later articles of this series.

IronWASP also has the ability to support most of the data formats commonly used in Request bodies. IronWASP can of course scan regular x-www-form-urlencoded formats but in addition it also supports JSON, XML (Web Services) and Multi-Part formats. The hallmark of IronWASP has been that you can add support for any data format you want by creating what is known as a Format Plugin. Users have been able to use this feature to scan Java Serialized Objects, WCF traffic and application specific custom formats. More information about Format Plugin will be made available in the later articles of this series.

The five scanning modes are:

  1. Mode 1 – Full Automated Site Crawl and Scan
  2. Mode 2 – Automated Scan of Manually Crawled sections of the Site
  3. Mode 3 – Automated Scan of Requests Selected with a Search Filter
  4. Mode 4 – Automated Scan of a specifically selected Request and its Selected Parameters
  5. Mode 5 – Automated Scan Created with the Scripting API

In each of these modes if the scanner identifies any vulnerabilities then it is immediately added to the vulnerability tree on the left-hand side of IronWASP interface. The scanner also leaves a detailed scan trace, we will be looking at the scan trace feature in the next article in the series.

Creating scans with Modes 1-4 is very easy as there is a wizard that helps you through the process. Let’s see how these wizards for each of these modes can be launched and what it does.

Mode 1 – Full Automated Site Crawl and Scan:

In this mode the user only has to enter the URL of the site that needs to be scanned. IronWASP visits the URL and then tries to crawl the entire site by following all links and submitting any forms it encounters. As the crawler identified news pages they are sent to the scanner for vulnerability scanning.

Figure 1: Starting a new scan on which is a test site maintained by the IBM AppScan team

To start a scan this way go to the Console section of IronWASP and enter the URL of the target in the input box provided and hit ‘Start Scan’. This will open up a wizard which will check if the target URL is reachable. If it is reachable then it will let you customize the different properties of the scan. If you are not an expert then you can proceed with just the default values. At the last step there is an option available to save all the configuration to a template file. The next time you are trying to start a new scan you can just use this template file rather than providing all the configuration details again.

Figure 2: After entering the target URL and clicking ‘Start Scan’ a wizard appears. This wizard will help with the creation of the scan

Once the scan is started the console section will show the scan status details. Currently it shows how many requests were identified by the crawler, how many of these requests have been used to create scan jobs and how many scan jobs are completed. A scan job is the smallest unit of the scanning task, the scan of the entire site is split in to these smaller units and you can view the status and details of each of the scan jobs from the Automated Scanning section.

Figure 3: After the scan is started the Console section shows the status of the scan

In this mode the crawler could revisit the same page multiple times and so the scanner might end up scanning the same page more than once. There is an option to avoid this, in the wizard there is a checkbox named ‘Prompt me for Assistance during the Scan’. If this is selected then scanner will ask the user for assistance whenever it encounter a duplicate item queued for scanning. The user can decide if it needs to be scanned or not. In my experience I have found that this mode reduces the scanning duration by as much as 80% by avoid scanning same items again.

Figure 4: The Scan Jobs created by the scanner can be seen here. It is possible to see that there are multiple duplicate entries. For example scan ids 45, 46, 47, 48 and 54 are all scanning the same search page

NOTE: Scanning very large sites in this mode can lead to IronWASP running out of memory and throwing exceptions. This is a known issue and hopefully it would be fixed in one of the future versions

Mode 2 – Automated Scan of Manually Crawled sections of the Site:

In this mode the user configures the browser to use IronWASP as the proxy server and then manually crawl the website. By default IronWASP proxy listens on port 8081. Alternatively if the user has a favourite crawler or Selenium scripts for traversing the website then they can be used (with IronWASP proxy configured as their upstream proxy) to crawl the website as well.

Figure 5: The Proxy section shows that the proxy is listening on port 8081

As the site is crawled IronWASP builds and displays a sitemap of the website on the left-hand side of the IronWASP interface. Now the user can right-click on the hostname of the site or on any of the different sections of the site in the sitemap and launch a scan from there. When this is done the scan is performed on the requests available in the proxy logs of IronWASP that belong to the selected site or selected section of the site.

Figure 6: Starting a scan on all the pages belonging to from the proxy logs

Figure 7 – Starting a scan on only the pages belonging to the search.aspx section of from the proxy logs

Figure 8: The scan creation wizard for this mode

In this mode by default the scanner prompts for user assistance to avoid scanning duplicate items from the log. This mode also allows the user to make use of Session Plugins to handle authentication and other custom site behaviour.

Mode 3 – Automated Scan of Requests Selected with a Search Filter:

Similar to Mode 2, in this mode also you would have to set IronWASP as the proxy and capture logs. Once this is done this mode gives a more fine grained control over which requests. The Logs section of IronWASP has a feature to search the logs with specific search filter.

Figure 9: The Search and Analyze Logs button launches the log search feature

Figure 10: Doing a search with a filter that will only select requests with GET method belonging to the hostname and having the character ‘?’ in the URL (referring to URLs with a query string)

The user would first launch the log search feature and search the logs with the desired filter. Once the search results are displayed the user can either select all the requests from the search results or individually select a few requests from the results. Once the selection is done the scan can be launched on all the selected requests.

Figure 11: The search results show the requests from the log that matched the filter. Two of these are selected and the ‘Scan Selected Requests’ button is clicked to launch the scan

Figure 12: Wizard to create scan in Mode 3

Mode 4 – Automated Scan of a specifically selected Request and its Selected Parameters:

This mode gives the highest amount of scan precision. Once you have capture some requests in the logs you can go to the Logs section and right-click on an individual log entry and launch a scan on that request. When doing this a wizard appears that lets the user specify all the scan settings. The user is able to edit or modify the request that needs to be scanned. Then the security checks that need to be performed must be selected. After this the user needs to specify which parameters in the request must be scanned. Here the user has the ability to select all parameters or just one single parameter. The wizard automatically identifies the number of injection points in the selected request to help the user select which ones need to be scanned.

Figure 13: To scan in Mode 4 select a request from the log and right click on it. Then click on the ‘Select Request for Automated Scanning’ option

Figure 14: Mode 4 scan wizard is launched and it shows the request from the selected log. If the user wants the request can be edited here before going to the next step.

Figure 15; The security checks that needs to be performed during the scan can be selected here.

Figure 16: The parameters or sections of the Request that needs to be scanned can be specified here. The user has the ability to specify just one parameter or select all parameters.

If the Request body is JSON, XML or Multipart post then it is automatically detected and injection points are set accordingly.

However if the body is of a custom format then there is also an option to manually place injection points in any section of the request body and it will be scanned.

Figure 17: A Request body with custom data format is being scanned. To set injection points go in to the Body tab and select the ‘Custom/Unknown Format’ radio button.

Figure 18: Select the section of the body that needs to be treated as an injection point and click on ‘Place injection markers in selected area’

Figure 19: The ‘Start Marker’ and ‘End Marker’ values are set before and after the selected are denoting that this is an injection point. You can now select another section of the request and set more injection points if needed. After that click ‘Apply’ to make the scanner detect the injection points.

Figure 20: The scan has detected one injection point now. It will treat this as any normal injection point and scan it.

After this, if needed, the user is able to customize the scan to handle Login, CSRF tokens, Multi-step form submissions or any other custom site behaviour using the Session Plugin feature.

Figure 21: As a last step the scan can be customized by selecting creating a Session Plugin

Mode 5 – Automated Scan Created with the Scripting API:

This mode allows creation of scans from the scripting shell using Python or Ruby. We will see how this is done in one of the later articles off the series where I cover scripting.
This is it guys. Hope you are able to use this information during your security testing to automatically identify security issues against websites. There is some more scanning than what was discussed here, some of it will be covered in next month’s article. IronWASP has one of the most versatile and feature packed scanning engines in the industry, hope you are able to benefit from it.

Lavakumar is the author of IronWASP, the advanced Web Security Testing Platform. He has also authored many other security tools like ‘Shell of the Future’, JS-Recon, Imposter and the HTLM5 based Distributed Computing System – Ravan. He has spoken at multiple conferences like BlackHat, OWASP AppSec Asia, ClubHack, Securitybyte, Nullcon, etc.

Leave a Reply