Attack Policy

This panel allows you to select the list of attack types, attacks locations, such as directory, file, or path, and other properties.

The following elements are available on this panel:

Attack Policy Template

This dropdown list contains the available attack policies and a Load button to load the selected template. The Predefined attack templates are as follows:

  • All Modules - Enables all attack modules. This template provides the most comprehensive coverage of vulnerabilities but also requires the most resources. If possible, you should host you application locally when using this attack template so that it does not affect the performance of customer-facing websites.
  • Crawl only - Deselects all attack modules. This template makes an inventory of all the web pages in your app and helps you understand its topology. You can either run an unauthenticated crawl scan to discover all the public facing resources of your app, or an authenticated scan to list all the internal as well as external resources. Clicking the Crawl Map button on the Scan page reveals the topology of the app discovered through the scan.
  • OWASP 2013 - Enables attacks related to the most critical web application security risks listed in the OWASP 2013 report.
  • OWASP 2017 - Enables attacks related to the most critical web application security risks listed in the OWASP 2017 report.
  • Passive analysis - Enables only passive analysis modules.
  • SQL Injection - Includes all SQL Injection related attacks.
  • XSS - Enables all attacks related to Cross-site Scripting.
  • SQL Injection and XSS - In many real-life scenarios, attackers use a combination of SQL Injection and Cross-site scripting vulnerabilities to gather sensitive data from your application. This template gives you an overall picture of such vulnerabilities in your application.

Note

To change the current policy, you must switch the template from the “Attack Policy Template” dropdown and click the Load button to apply its settings.

You can save currently selected modules as a custom policy using the Save button. The custom policies are located in the AppSpider data folder under the "AttackPolicy" directory. Each policy is located in a separate file. If a custom policy name matches a scanner default policy name, then the custom policy overwrites the scanner default policy.

The interface merges default scanner policies with user policies in the Attack policy template list.

Attack Policy tab

The attack policy tab lets you configure the following properties:

Property

Description

Attack Policy Name

Name of the attack policy template.

Attacks Prioritization

Controls the order in which AppSpider attacks are run on target URLs.
Values:
* Sequential - AppSpider will run all attacks on the first link, then switch to the next link, and so on. This is easier for troubleshooting, if you want to figure out which module is causing trouble while scanning your web applications.
* Smart - AppSpider uses a Rapid7 proprietary attack prioritization algorithm.
* Randomized - AppSpider randomly selects a link from the attack space to run attacks on. Randomized attacks are harder to detect as automated traffic by firewalls.

Attacks per input

Controls the number of attacks run by AppSpider on every link.
Values:
* All - All potential attacks are made.
* Smart - AppSpider uses a Rapid7 proprietary attack selection to minimize redundant attacks.
* Time - Attacks that take less time are run before attacks which run longer.

Attacks Collection

Values:
* All - all attacks from all collections.
* Smart - Rapid7 uses a proprietary algorithm to select the best attack collection to run for a particular attack point.

Browser Encoding

Many web applications and firewalls test incoming requests against a limited set of character encodings, like UTF-8 and UTF-16. AppSpider encodes attack traffic using a variety of character encodings so it can pass through your firewall and attack your application. The "Browser Encoding" field instructs AppSpider that attacks should only be encoded in the default encoding of the browser.
Values:

* No - AppSpider can encode attack requests using a variety of character sets to bypass firewalls.
* Yes - AppSpider should only encode attack requests using the character sets specified by the browser.

False Positive Regex

AppSpider might incorrectly associate certain pages of your applications with 4xx error codes. If you believe that legitimate messages in your web application are being flagged as vulnerabilities, you can add their content to the False Positive Regex field to prevent False Positive results.

For example, the message "This web browser does not support JavaScript or JavaScript in this web browser is not enabled" is only meant to notify the user of missing functionality and is not an indicator of a web application vulnerability. If AppSpider incorrectly flags this as an error message, you can add this string in the False Positive Regex field.

Module Policy tab

An attack module contains the details of a vulnerability and the logic used by AppSpider to test for that vulnerability. The "Module Policy" table lists all the attack modules, and displays the following information:

  • Module Name - Identifies the vulnerability AppSpider will detect, such as SQL Injection or File Traversal.
  • Type - Whether the module is an active or passive attack.
    • Passive - These attacks do not send active payloads to your website -- examples include misconfigured headers or missing tags such as “autocomplete”.
    • Active - These modify query strings, POST and GET requests to search for vulnerabilities that require active manipulation of your site. Examples include SQL Injection and OS Commanding.
  • Severity - The default severities can be modified depending on their impact to your requirements, such as enhanced compliance needs.
  • Max Findings - The count of findings we will report before we ignore subsequent findings. These are useful in the case of site-wide findings. If your application has misconfigured headers, for example, this can affect the entire site. Reporting this vulnerability for each page of your site will just increase alert fatigue. This example is usually remediated in one spot -- the server configuration.
  • Description - A brief synopsis of the module’s goals.

Attack locations tab

This screen contains the list of attacks with options to select the attack location, such as Directory, File, Query, and Post.

You can use this screen to prevent attacks from being run on unselected locations. For example, if a new comment on your application triggers a notification email, you may decide to prevent attacks from running on 'Post' locations.