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.
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:
Attack Policy Name
Name of the attack policy template.
Controls the order in which AppSpider attacks are run on target URLs.
Attacks per input
Controls the number of attacks run by AppSpider on every link.
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.
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.
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.