Configure Vulnerability Checkers

A vulnerability checker is a Seeker component that detects a certain type of vulnerability by analyzing information collected by an Agent.

You can access this task either for a single project or for a project template by doing the following:

• For a project: In the main menu, click (Projects) and open a project that you want to configure. Click Analysis.
• For a project template: In the main menu, click (Settings) > Project Templates. Open an existing template for editing, or add a new one, and click the Analysis tab.

A list of all available checkers is displayed. You can filter the list by choosing the technologies relevant for the current project and/or by text contained in the checker's name. Click a checker's name to view a detailed description of the checker.

You can do the following:

Manage checkers

• For project templates and projects not linked to project templates, reset the configuration of all checkers to their defaults by clicking Reset to defaults. This includes the default severity level and custom aggregation rules.
  CAUTION: This operation cannot be undone. But you can later configure any checker as required.
• Export the full list of checkers in PDF format by clicking the Export button.
• Enable or disable a checker for the current project by toggling the On/Off switch.

  By default, all the checkers are enabled, but you might want to disable some of them if their detections are not relevant for this project. The status of a checker takes effect for all the technologies to which the checker applies.

• View the details of a checker by choosing Details from the (cog) menu in its row.
• Configure various settings for any checker, as described in the following sections.

Configure a checker

1. From the (cog) menu, choose Configure.
2. In the dialog box that opens, configure the settings specific for the current checker, if any.
3. Configure the HTTP response option.
   Note: This option is available for any checker detecting vulnerabilities that could be triggered by an HTTP request. It is enabled by default for the checkers in which responses are most useful to understand a vulnerability.
   Warning: Choosing this option might impact your application performance and increase the Seeker database size.
   Toggle the Display HTTP responses with reported vulnerabilities option.
4. Save your changes.

Change the default severity level assigned by a checker to vulnerabilities upon detection

1. From the (cog) menu, choose Configure severity.
2. In the dialog box that opens, select the appropriate severity level from the dropdown list.
3. If there are vulnerabilities previously detected by this checker, you can assign to them the new severity level by choosing Yes from the dropdown list.
4. Save your changes.

Configure custom aggregation rules for this checker

To decrease the number of instances of the same vulnerability detected by a checker, Seeker aggregates such detections into a limited set that represents the whole set. You can customize this process by configuring your own aggregation rules for any checker.

1. From the (cog) menu, choose Configure aggregation rules.
2. In the dialog box that opens, select one or more of the conditions by which you want to aggregate newly detected vulnerabilities: Endpoint, Source name, and Code location.
   Note:

   During testing, multiple instances of the same vulnerability that match all the selected conditions will be aggregated into one vulnerability. The more conditions you enable, the less instances will be aggregated. Disabled conditions will be ignored.

   For example, you have several vulnerability instances detected for the same checker, such as Cross-Site Scripting, which have different endpoints but the same parameter and code location. If you disable the Endpoint condition, all these instances will be aggregated into one vulnerability.

   The available conditions and their default values differ between checkers.

   • By endpoint: for example, http://my-site.com/WebGoat/attack5/b?param=ssss
     • Request URI : for example, /WebGoat/attack5/b?param=ssss
     • Context Path: for example, /WebGoat
     • Disabled
   • By source name: such as a parameter name, header, cookie, and more.
     • Enabled
     • Disabled
   • By code location: the method or function where the vulnerable code is located.
     • Enabled
     • Disabled
3. The current aggregation rules are not applied to existing vulnerabilities previously detected by this checker. If you have such vulnerabilities in your list, they will be duplicated by new detections. You are prompted to delete them or change their status to Archived.
4. Save your changes.

Configure restricted code for the Usage of Restricted Code checker

1. Locate the Usage of Restricted Code checker in the list.
2. From the (cog) menu of the checker, choose Configure. In the dialog box that opens, configure one or more rules to define restricted code:
3. Select the technology of the method or function, and enter its code path pattern and library version pattern. You can use wildcards for patterns.
4. Click Add rule.
5. When done, save your changes.

Configure session timeout for the Insufficient Session Expiration checker

This checker detects when a session has not expired after a predefined timeout. This timeout is by default 20 min, but you can configure it as required.

1. Locate the Insufficient Session Expiration checker in the list.
2. From the (cog) menu of the checker, choose Configure.
3. In the Configure Session Timeout dialog box that opens, change the timeout value as required.
4. Save your changes.