About Privilege Escalation Scans

Privilege escalation vulnerabilities result from programming errors or design flaws that grant an attacker elevated access to an application and its data. Fortify WebInspect can detect privilege escalation vulnerabilities by conducting either a low-privilege or unauthenticated crawl followed by a high-privilege crawl and audit in the same scan. Fortify WebInspect includes a Privilege Escalation policy as well as privilege escalation checks that can be enabled in other policies, including custom policies. In Guided Scan, Fortify WebInspect automatically detects when you have selected a policy with privilege escalation checks enabled, and prompts you for the required login macro(s).

Two Modes of Privilege Escalation Scans

Fortify WebInspect can perform privilege escalation scans in two modes, determined by the number of login macros you use:

What to Expect During the Scan

When conducting a scan with privilege escalation checks enabled, Fortify WebInspect first performs a low-privilege crawl of the site. During this crawl, the Site view is not populated with the hierarchical structure of the Web site. Nor are vulnerabilities populated in the Summary pane. However, you can confirm that the scan is actively working by clicking the Scan Log tab in the Summary pane. You will see messages in the log indicating the "Scan Start" time and the "LowPrivilegeCrawlStart" time. When the low-privilege crawl of the site is complete, the high-privilege crawl and audit phase of the scan occurs. During this phase, the Site view will be populated and any vulnerabilities found will appear in the Summary pane. For more information, see Summary Pane.

Regex Patterns Used to Identify Restricted Pages

If your site includes restricted pages that are blocked using text such as “Forbidden,” “Restricted,” or “Access Denied,” the Privilege Escalation check includes a regex pattern that determines that these pages are forbidden for the current user. Therefore, these pages are not identified as being vulnerable for privilege escalation. However, if your site uses other privilege restriction text that does not match the built-in regex pattern, you must modify the regex to include your own text patterns. Otherwise, the Privilege Escalation check may generate false positives for those pages.

Modifying Regex for Privilege Restriction Patterns

  1. Click Edit > Default Scan Settings.

    The Default Settings window appears.

  2. Select Attack Exclusions in the Audit Settings group.

  3. Click Audit Inputs Editor….

    The Audit Inputs Editor appears.

  4. Select Check Inputs.

  5. Select check 11388 Privilege Escalation.

    The Privilege Restriction Patterns appear in the right pane. By default, the pattern is as follows:

    ‘forbidden|restricted|access\sdenied|(?:operation\snot\s(?:allowed|permitted|authorized))|(?:you\s(?:do\snot|don’t)\shave\s(?:access|permission|authorization))|(?:you\s(?:are\snot|aren’t)\s(?:allowed|permitted|authorized))’

  6. Using regex syntax, add any new forbidden action words that are used in your site.

  7. Click OK to save the revised Check Inputs.

  8. Click OK to close the Default Settings window.

Effect of Crawler Limiting Settings on Privilege Escalation Scans

Fortify WebInspect audits each parameter value during a scan. Therefore, a Privilege Escalation scan is sensitive to settings that limit the crawler, such as:

For example, if you set “Limit maximum single URL hits to” 1 and the site contains links such as:

		   index.php?id=2
index.php?id=1
index.php?id=3

then during the high-privilege scan, Fortify WebInspect finds “index.php?id=1” and during the low-privilege scan, it finds “index.php?id=3”. In this scenario, Fortify WebInspect will mark “index.php?id=1” with a Privilege Escalation vulnerability. This vulnerability will be a false positive.

For more information, see Scan Settings: General.

Effect of Parameters with Random Numbers on Privilege Escalation Scans

If the site contains parameters with random numbers, you can add the parameter to the list of HTTP Parameters Used For State to exclude such sessions from audit and reduce the number of false positives.

For example, for the following parameter:

		   index.php?_=1440601463586
index.php?_=1440601465662
index.php?_=1440601466365

you would add the parameter to the list of HTTP Parameters Used For State as shown below:

For more information, see Scan Settings: HTTP Parsing.

See Also

Running a Basic Scan (Web Site Scan)

Using the Predefined Template

Using the Mobile Scan Template

Using the Native Scan Template