Web Application Scanning

Web Application Scanning

  • Black-box web application scanning, if we abstract from the details, is a simple process
    1. Identify all links, forms, query string parameters.
    2. Send specially crafted strings to each input and analyze the output
    3. Generate a report with the findings
  • 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.

w3af’s architecture

  • The w3af framework is divided into three main sections:
    1. The core, which coordinates the whole process and provides libraries for using in plugins.
    2. The user interfaces, which allow the user to configure and start scans
    3. The plugins, which find links and vulnerabilities

w3af’s phases

  • w3af follows the steps you would perform 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.

Configuration

  • The framework can be configured using two very different settings: plugin configuration and global configuration

Plugin 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.

Global 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.

Saving your settings

  • 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.

References

Flag Counter