OWASP London, 29th March 2012 IronWASPOpen Source Web App Testing Framework • Manish S. Saindane • email@example.com
WHOAMI • Sr. Security Consultant @ GDS Security London (http://www.gdssecurity.com/) • Co-author security website/blog Attack & Defense Labs (http://andlabs.org) • Contributor to IronWASP and maintain the Ruby plug-in repo. • Speaker at BlackHat EU 2010, InfoSecurity India 2007
What is IronWASP? • Open Source framework for Web Application Security Testing • Designed for optimum mix of Manual and Automated Testing • Designed for Pentesters and QA folks • Allows designing customised penetration tests • Easy to use GUI and Advanced scripting capability
Why IronWASP? • Customise penetration tests • Reduce retest efforts • Smart enough but honest about its limitations • Provide complete freedom for the pentester to modify it as he/she sees fit
IronWASP API • HTTP Request/Response Classes • Scanner, Encoders/Decoders, Other useful methods • HTML Parsing • Complete access to IronWASP functionality • Documentation available in GUI
Scripting Shell • One of the most exiting component of IronWASP • Python/Ruby scripting REPL • Full access to the framework with IronWASP API • Programmatic analysis of logs, create custom fuzzers from existing requests or craft new requests, etc.
Plug-ins • Written in Python/Ruby using the IronWASP API • Easy to modify existing plug-ins • Can easily add new custom plug-ins • UI based API doc provided inside the tool • Syntax highlighting Script Editor with basic error checking support built-in
Plug-ins • IronRuby plug-ins: • https://github.com/msaindane/IronWASP-Ruby-Plugins • IronPython plug-ins: • https://github.com/Lavakumar/IronWASP-Python-Plugins
Format Plug-ins • Deal with custom data formats in the Request/Response body • Used with the Active plug-ins to fuzz almost* any data format • E.g. • WCF Binary, JSON, AMF, etc. *Any data format that can be converted to XML and back
Session Plug-ins • Every site has slight variations in Authentication, Session handling, CSRF protections, Logic-flow, etc. • Automated Scanners usually do not understand this but testers do ! • Testers need to feed this info into the Scanner
Session Plug-ins • Allows the tester to build custom logic needed to scan a particular application • Used along with the Active plug-ins • E.g. • Multi-step forms • Dynamic login functionality
Passive Plug-ins • Passive analysis of Web traffic and spot vulnerabilities • Ability to modify traffic based on custom logic • E.g. • Passwords sent over clear-text • Cookie and Header analysis
Active Plug-ins • Automated vulnerability identification • Need to be explicitly called by the user • Fine grained scanning support • E.g. • Cross-site Scripting, SQL Injection, etc.
Q’s, Comments, Feedback • Mailing List: http://groups.google.com/group/ironwasp • Lavakumar: @lavakumark / firstname.lastname@example.org • Manish: @msaindane / email@example.com • Website: http://ironwasp.org
Thanks to • Gotham Digital Science • The security community • Everyone who helped with testing and feedback http://ironwasp.org/about.html#credits