Skip to content

Detecting vulnerabilities

What is a vulnerability?

A vulnerability is an error made due to negligence or inadequate information when building or implementing a web application that can lead to an information security risk. The information security risks are:

  • Unauthorized data access: for example, access to read and modify user data

  • Denial of service

  • Data corruption and much more

Vulnerability detection methods

When scanning the application for open vulnerabilities, Wallarm WAF sends requests with attack signs to the protected application address and analyzes application responses. If the response matches one or more pre‑defined vulnerability signs, Wallarm WAF records open vulnerability.

For example: if the response to the request sent to read the /etc/passwd contents returns the /etc/passwd contents, protected application is vulnerable to the Path Traversal attacks. Wallarm WAF will record the vulnerability with an appropriate type.

To detect vulnerabilities in the application, Wallarm WAF sends requests with attack signs using the following methods:

  • Passive detection: the vulnerability was found due to the security incident that occurred.

  • Active threat verification with the main component Attack rechecker lets you turn attackers into penetration testers and discover possible security issues from their activity as they probe your apps/APIs for vulnerabilities. The module Attack rechecker finds possible vulnerabilities by probing application endpoints using real attack data from the traffic.

  • Vulnerability scanner: all elements of the scope are scanned for typical vulnerabilities.

Passive detection

With passive detection, Wallarm WAF detects a vulnerability due to the security incident that occurred. If an application vulnerability has been exploited during an attack, Wallarm WAF records the security incident and the exploited vulnerability.

Passive vulnerability detection is enabled by default.

Active threat verification

How it works

Based on the initial detected attacks, Attack rechecker creates a lot of new test requests with different payloads attacking the same endpoint. This mechanism allows Wallarm to detect vulnerabilities that could be potentially exploited during attacks. The Attack rechecker process will either confirm that the application is not vulnerable to the specific attack vectors or find actual application security issues.

List of vulnerabilities that can be detected by the module

The Attack rechecker process uses the following logic to check the protected application for possible Web and API security vulnerabilities:

  1. For every group of malicious request (every attack) detected by a Wallarm WAF node and uploaded to the connected Wallarm Cloud, the system analyzes which specific endpoint (URL, request string parameter, JSON attribute, XML field, etc) was attacked and which specific kind of vulnerability (SQLi, RCE, XSS, etc) the attacker was trying to exploit. For example, let's take a look at the following malicious GET request:

    https://example.com/login?token=IyEvYmluL3NoCg&user=UNION SELECT username, password
    

    From the request the system will learn the following details:

    • The attacked URL is https://example.com/login
    • The type of used attack is SQLi (according to the UNION SELECT username, password payload)
    • The attacked GET request parameter is user
    • Additional piece of information provided in the request is the request string parameter token=IyEvYmluL3NoCg (it is probably used by the application to authenticate the user)
  2. Using the collected information the Attack rechecker module will create a list of about 100-150 test requests to the originally targeted endpoint but with different types of malicious payloads for the same type of attack (like SQLi). For example:

    https://example.com/login?token=IyEvYmluL3NoCg&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm
    https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+SLEEP(10)--+wlrm
    https://example.com/login?token=IyEvYmluL3NoCg&user=1);SELECT+PG_SLEEP(10)--
    https://example.com/login?token=IyEvYmluL3NoCg&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm
    https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10))
    https://example.com/login?token=IyEvYmluL3NoCg&user=%23'%23\x22%0a-sleep(10)%23
    https://example.com/login?token=IyEvYmluL3NoCg&user=1';+WAITFOR+DELAY+'0code:10'--
    https://example.com/login?token=IyEvYmluL3NoCg&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm
    https://example.com/login?token=IyEvYmluL3NoCg&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/
    
  3. The Attack rechecker module will send generated test requests to the application bypassing the WAF protection (using the white-listing feature) and verify that the application at the specific endpoint is not vulnerable to the specific attack type. If Attack rechecker suspects that the application has an actual security vulnerability, it will create an event with type incident.

    User-Agent HTTPS header value in Attack rechecker requests

    The User-Agent HTTP header in Attack rechecker requests will have the value Wallarm attack-rechecker (v1.x).

  4. Detected security incidents are reported in the Wallarm Console and are able to be dispatched to your security team via available third-party Integrations and Triggers.

Potential risks from the Attack rechecker activity

In rare cases when a legitimate request is detected by the WAF as an attack, the request will be replayed by Attack rechecker. If the request is not idempotent (for example, an authenticated request creating a new object in the application), then the Attack rechecker requests may create many new unwanted objects in the user account or perform other unexpected operations.

To minimize the risk of the described situation, Attack rechecker will automatically strip the following HTTP headers from the replayed requests:

  • Cookie

  • Authorization: Basic

  • Viewstate

Configuration

The module Attack rechecker should be properly configured to work correctly. Please learn the Attack rechecker configuration options and best practices for these options setup from this document.

Vulnerability scanner

How it works

Vulnerability scanner checks all elements of the company scope for typical vulnerabilities. The scanner sends requests to application addresses from fixed IP addresses and adds the header X‑Wallarm‑Scanner‑Info to the requests.

Configuration

False positives

False positive occurs when attack signs are detected in the legitimate request or when legitimate entity is qualified as a vulnerability. More details on false positives in attack detection →

False positives in vulnerability scanning may occur due to the protected application specificities. Similar responses to similar requests may indicate an open vulnerability in one protected application and be expected behavior for another protected application.

If a false positive for a vulnerability is detected, you can add an appropriate mark to the vulnerability in the Wallarm Console. A vulnerability marked as a false positive will be switched to an appropriate status and will not be rechecked. More about managing false positives via the Wallarm Console →

If the detected vulnerability exists in the protected application but cannot be fixed, we recommend setting up the Create a virtual patch rule. This rule will allow blocking attacks exploiting the detected type of vulnerability and will eliminate the risk of an incident.

Managing discovered vulnerabilities

All detected vulnerabilities are displayed in the Wallarm Console → Vulnerabilities section. You can manage vulnerabilities through the interface as follows:

  • View and analyze vulnerabilities

  • Run vulnerability status recheck: still opened or fixed on the application side

  • Close vulnerabilities or mark them as false positives

For more information on managing vulnerabilities, see the instructions on working with vulnerabilities.

Vulnerabilities section