IronWASP: An introduction
Security scanners have always played an important role during penetration testing. It helps save a lot of resources as automated testing plays a big role in these scanners. In a single scan, security scanners help us check for a number of vulnerabilities that may be affecting our application. Considering not all vulnerability scanners are open source, a great deal of them are available such as:
- Retina CS Community
- Grabber, etc.
In this article, we shall be discussing more about IronWASP.
IronWASP (Iron Web Application Advanced Security testing Platform) is an open source tool used for web application vulnerability testing. It is designed in such a way that users having the right knowledge can create their own scanners using this as a framework. IronWASP is built using Python and Ruby and users having knowledge of them would be able to make full use of the platform. However, IronWASP provides with a lot of features are simple to understand.
Few features of IronWASP are as follow:
- Its GUI based
- Supports recording Login sequence
- Can generate reports in HTML as well as RTF formats
- Scans for over 25 different web vulnerabilities
- False positive detection support
- False negative detection support
- Built-in scripting engine that supports Python and Ruby
- Extensible via plug-ins or modules in Python, Ruby, C#, or VB .NET
- It is bundled with a number of modules built by independent security researchers such as WiHawk, IronSAP, CSRF PoC Generator, XMLChor, etc.
IronWASP can be downloaded from https://ironwasp.org/download.html and is available for Windows, Linux (requires Wine), and MacOS (requires CrossOver).
IronWASP’s repository can be found at https://github.com/Lavakumar/IronWASP
IronWASP tests for a number of vulnerabilities such as:
- XSS (Cross Site Scripting)
- Cross Site Flashing
- CSRF (Cross Site Request Forgery)
- Server Side Request Forgery
- File Inclusion
- Insecure Direct Object Reference
- Unrestricted File Upload Vulnerability
- Open URL Redirection
- Broken Authentication and Session Management
- Security Misconfiguration
- Sensitive Data Exposure
- Buffer Overflow
- Header Injection
- Missing Function Level Access Control
- HTTP Parameter Pollution
- Full Path Disclosure
- Source Code Disclosure
- Bruteforce Login
- Content Spoofing
- DoS (Denial of Service)
- Information Leakage
- XML Injection
- SSL Injection
- XPath/XQuery Injection
- SQL Injection
- LDAP Injection
- Command Injection
- Code Injection
- HTTP Verb Tampering
- Insufficient Session Expiration
- ORM Injection
- IMAP/SMTP Injection
- Expression Language Injection
As you can see, IronWASP covers a wide variety of vulnerabilities.
Scanning a simple web page
A page called ‘test.php‘ has been intentionally coded in a way that it is vulnerable to XSS (Cross Site Scripting). Since IronWASP relies heavily on the sitemap, if present, we will directly try to scan the vulnerable page in this case. Once downloaded, simply click on IronWASP.exe and you are good to go:
This allows us to configure (optional) IronWASP before we start using it. For this scenario, we will be using the default settings and simply press ‘Start IronWASP.’ We will be presented with the home screen with a long text box asking us to enter the URL we want to scan. We will enter the link of the page, in this case, ‘http://out.co/test.php‘ (marked in blue) and click on ‘Start Scan‘:
Let’s see if IronWASP can detect the vulnerability. However, before it does that, it also provides with a number of further customizable options.
The first option checks whether the host we have entered in reachable or not:
The Crawl settings provide us with further options which are self-explanatory. In unsure, it is advised to leave them as they are.
The Scope settings help us to tell the scanner what all should it scan and what all should be left out. Sub-domains should be scanned or not, HTTPS pages, etc. Since we are working on a single page, we will leave them as they are:
The Scan Setting helps us choose the vulnerabilities we want IronWASP to scan for the pre-defined scope of pages. It also gives us the option to test different requests such as:
- URL path Parts
Since we know that the page is vulnerable to Cross-Site Scripting (XSS), we will be telling IronWASP to check only that:
The Scan Filter setting helps us tell IronWASP to Include/Reject certain parameters of the Body and the Query. Since we do not have such requirement, we will be using the default setting:
Now we are ready to scan the page. One last option that is provided to us is of ‘Assistance during the scan.’ What this means is IronWASP will ask for your input while scanning requests. Since we are just scanning a single page, this is not required. IronWASP also gives us the option to save the settings we just made as a configuration file which we may be able to use in other scans as well. This would save time since we will not be required to go through this process again (marked in blue):
Now our scan will begin.
As we can see, IronWASP has successfully identified Cross-Site Scripting on the ‘name‘ parameter. As we all know, we should never solely rely on the results produced by a scanner. We shall confirm this by doing a manual test:
Moreover, it is confirmed. Our page ‘test.php‘ is vulnerable to Cross-Site Scripting (XSS) on parameter ‘name.’
In Part 2 we will see how IronWASP reacts to more complex web applications and other complex scenarios.