_ w3af is a Web Application Attack and Audit Framework _
The project’s goal is to create a framework to find and exploit web application vulnerabilities that is easy to use and extend.
One of the most difficult parts of securing your application is to identify the vulnerable parameters and define the real risk. This video shows how to easily identify and exploit SQL injection vulnerabilities. As bonus the video shows how to extract information using web application payloads.
Want to know more about the low-level features provided by our framework? Go through our features page in order to understand what’s under the hood.
Vulnerabilities are identified using plugins , which are short and sweet pieces of Python code that send specially crafted HTTP requests to forms and query string parameters to identify errors and mis-configurations.
Easy to use for novice users, fully customizable for hackers and developers. We’ve built it that way.
Besides the automated scanning features w3af’s GUI provides expert tools which allow the advanced users to manually craft and send custom HTTP requests, generate requests in an automated manner, cluster HTTP responses and more!
w3af is a simple tool to use once you understand the basic concepts behind it, our FAQ and the framework’s feature list will introduce you to the overall idea, but this document will dive into w3af and explain all you need to know before running a scan.
Black-box web application scanning, if we abstract from the details, is a simple process:
Due to various reasons that won’t be discussed in this document, this process is actually very complex and false positive/negative prone if done without the right tools.
The w3af framework is divided into three main sections:
w3af follows the steps you would perfom in a web application penetration test, see “Web Application Scanning” above. In order to do so it defines different types of plugins which are going to be called by the core in a specific order.
Starting with a target URL provided by the user, w3af will first try to identify all URLs, forms and query string parameters in the application by the means of crawl plugins . A very good example of this type of plugin is the web_spider which will extract URLs from a page, follow those links and once again extract URLs from it. Following that process it will create a complete application link and form map.
Once the application has been mapped, audit plugins will send specially crafted strings to each parameter in order to trigger bugs in the application’s code. When a bug is found it will be reported to the user. The most used audit plugin is sqli which will find error-based SQL injections.
Identified vulnerabilities, debug and error messages, all are reported to the user with output plugins . These plugins will write the messages in different formats to suit your needs. In most cases a text file is what users need, but for integration into other tools XML file format is also available.
The framework can be configured using two very different settings: plugin configuration and global configuration.
Plugins might have configuration parameters, in all cases where the plugin has a setting a default value has been set. We recommend you read the setting help and in some cases the plugin source code in order to understand exactly what will happen if you change the configuration.
The framework-wide configuration settings change the core’s behavior and are split in two: http-settings and misc-settings. As with the plugin configuration, all settings in the global configuration have a default value and should be changed with care. Changing a setting here might reduce the scanner’s performance, have the framework generate thousands of unnecessary HTTP requests, etc.
All user defined settings can be saved using profiles, this helps users run their scans multiple times and in some cases run them with slightly different configurations. Creating, saving and loading profiles is an easy task that’s done from within the user interface.
Before diving into our HOWTO documents we recommend you go through understanding the basics document which will help you understand some concepts used in the next sections.
Although we would like to have all HOWTO documents in our site, others have written excelent documents about w3af at third-party sites and we think you might find them interesting as well.
If you’re a Linux, BSD or Mac user we recommend you download the source from our GitHub repository:
git clone https://github.com/andresriancho/w3af.git cd w3af ./w3af_gui
After running this command you’ll get a list of unmet dependencies and the commands to be run in order to install them. Best case scenario, you’ll have w3af up and running in just a few minutes and only by running the commands returned by
The framework has two different sets of dependencies, one for the GUI and one for the Console, in case you don’t want to use the GUI, just run
w3af_console and install those dependencies.
While old versions of w3af worked on Windows the latest version of w3af hasn’t been tested on this platform.
Mainly because of the project’s goals and objectives, Team is not planning to update the Windows installer unless we get funding for it through the “A Windows installer for w3af” crowdfunding project.