Help Center/ Web Application Firewall/ User Guide/ Configuring Protection Policies/ Configuring Protection Rules/ Configuring Basic Web Protection to Defend Against Common Web Attacks
Updated on 2025-08-19 GMT+08:00
View PDF
Share

Configuring Basic Web Protection to Defend Against Common Web Attacks

After a website is connected to WAF, General Check (with Default rule set (medium) selected and Log only configured for Protective Action) is enabled by default. Basic web protection can defend against common web attacks, such as SQL injection, XSS, remote overflow attacks, file inclusion, Bash vulnerability exploits, remote command execution, directory traversal, sensitive file access, command injection, and code injection. You can also enable Deep Inspection, Header Inspection, and Shiro Decryption Check to detect bypass attempts, and enable Web Shell Detection to detect web shells implanted through upload interfaces.

Common Web Attacks and Security Measures

Common web attacks include SQL injection, XSS, remote overflow attacks, file inclusion, Bash vulnerability exploits, remote command execution, directory traversal, sensitive file access, command injection, code injection, cross-site request forgery (CSRF), server request forgery (SRF), and website backdoors.

Basic web protection provides a rule set to defend against OWASP Top 10 threats. Leveraging proprietary anti-evasion technologies, basic web protection offers general check, deep inspection, header inspection, Shiro decryption check, and web shell detection to detect and block common web attacks.

Figure 1 Basic web protection
The detailed functions are as follows:
  • General Check: WAF defends against attacks such as SQL injections, XSS, file inclusions, Bash vulnerabilities, remote command execution, directory traversal, sensitive file access, and command/code injections.
    • WAF divides the built-in rule sets into three protection levels to meet different protection requirements.
      • Default rule set (loose): Only requests with obvious attack characteristics are blocked. With this rule set, the false positive rate decreases, but the false negative rate may increase.
      • Default rule set (medium) (default): This rule set meets web protection requirements in most scenarios.
      • Default rule set (strict): WAF provides the finest granular protection and can block attacks with complex bypass features, such as Jolokia cyber attacks, common gateway interface (CGI) vulnerability detection, and Druid SQL injection attacks. With this rule set, the false positive rate may increase, but the false negative rate decreases.
    • You can enable the detection of each attempt to bypass WAF as required.
      • Deep Inspection (disabled by default): WAF identifies and blocks evasion attacks, such as the ones that use homomorphic character obfuscation, command injection with deformed wildcard characters, UTF7, data URI scheme, and other techniques.

        This type of protection is not supported when it is disabled.

      • Header Inspection (disabled by default): WAF checks all header fields in received requests.

        When it is disabled, WAF General Check will check some of the header fields, such as User-Agent, Content-type, Accept-Language, and Cookie.

      • Shiro decryption check (disabled by default): WAF uses AES and Base64 to decrypt the rememberMe field in cookies and checks whether this field is attacked, with hundreds of known leaked keys included and checked for.

        This type of protection is not supported when it is disabled.

        If your website uses Shiro 1.2.4 or earlier, or your website uses Shiro 1.2.5 or later but no AES keys are not configured, it is strongly recommended that you enable Shiro decryption detection to prevent attackers from using leaked keys to construct attacks.

  • Webshell Detection: WAF protects web applications from web shells. HTTP/2 packets do not support web shell detection.

Suggestions

  • If you are not clear about your service traffic characteristics, you are advised to switch to the Log only mode first and observe the WAF protection for a period of time. Generally, you need to observe service running for one to two weeks, and then analyze the attack logs.
    • If no record of blocking legitimate requests is found, switch to the Block mode.
    • If legitimate requests are blocked, adjust the protection level or configure global protection whitelist rules to prevent legitimate requests from being blocked.
  • If you change the protection level to Default rule set (strict), false positives may occur, affecting normal services. Before make such a change, complete the following operations:
    • Change Protective Action to Log only first. Then, change the protection level to Default rule set (strict) and check whether false positives occur. If there are false positives, handle them and then change Protective Action to Block.
    • If you have concerns about changing Protective Action to Log only in Solution 1, you can directly change the protection level to Default rule set (strict). However, you still need to observe the protection events and handle false positives in a timely manner to prevent impact on normal services.
    • You can also submit a service ticket to enable the custom protection rule set. Create a custom rule set and set Protective Action of Default rule set (strict) to Log only. After that, check whether there are false positives. If yes, handle them promptly. After confirming that no problem exists, change Protective Action to Block.
  • Note the following points in your operations:
    • Do not transfer the original SQL statement or JavaScript code in a legitimate HTTP request.
    • Do not use special keywords (such as UPDATE and SET) in a legitimate URL. For example, https://www.example.com/abc/update/mod.php?set=1.
    • Use Object Storage Service (OBS) or other secure methods to upload files that exceed 50 MB rather than via a web browser.

Prerequisites

Constraints

  • Currently, Shiro decryption detection is not available in regions CN East-Qingdao and AP-Manila.
  • HTTP/2 packets do not support web shell detection.

Enabling Basic Web Protection Rules

  1. Log in to the WAF console.
  2. Click in the upper left corner and select a region or project.
  3. (Optional) If you have enabled the enterprise project function, in the upper part of the navigation pane on the left, select your enterprise project from the Filter by enterprise project drop-down list. Then, WAF will display the related security data in the enterprise project on the page.
  4. In the navigation pane on the left, click Policies.
  5. Click the name of the target policy to go to the protection rule configuration page.

    Before configuring protection rules, ensure that the target protection policy has been applied to a domain name. A protection policy can be applied to multiple protected domain names, but a protected domain name can have only one protection policy.

  6. Click the Basic Web Protection configuration box and ensure that the basic web protection rules are enabled.

    : enabled.

  7. Configuring Basic Web Protection

    Figure 2 Configuring protection rules
    Table 1 Basic web protection parameters

    Parameter

    Description

    Example Value

    General Check

    Function switch

    General Check is enabled by default. WAF defends against attacks such as SQL injections, XSS, file inclusions, Bash vulnerabilities, remote command execution, directory traversal, sensitive file access, and command/code injections. SQL injection attacks are mainly detected based on semantics.

    Protection level

    You can select the protection level of basic web protection based on your service requirements. The options are as follows:

    • Default rule set (loose): Only requests with obvious attack characteristics are blocked.

      If a large number of false alarms are reported, the loose one is recommended.

    • Default rule set (medium) (default): meets web protection requirements in most scenarios.

      If basic web protection is enabled, the protection level is medium by default.

    • Default rule set (strict): At this level, WAF provides the finest granular protection and can block attacks with complex bypass features, such as Jolokia cyber attacks, common gateway interface (CGI) vulnerability detection, and Druid SQL injection attacks.

      To let WAF defend against more attacks but make minimum effect on normal requests, observe your workloads for a period of time first. Then, configure a global protection whitelist rule and select the tight level.

    You can click View Rule Set Details to view the details of all rules in the rule sets at the three protection levels. Table 2 describes the protection rules.
    • You can set Start Date and End Date to search for the protection rules released within a specified period.
    • You can select filter CVE ID, Rule ID, or Rule Description and enter a keyword to search for a specific protection rule.
    • You can click next to CVE ID, Risk Severity, Application Type, or Protection Type to filter specified rules.

    Default rule set (medium)

    Check scope
    You can enable or disable a specific check in basic web protection. The options are as follows:
    • Deep Inspection (disabled by default): If you enable this, WAF identifies and blocks evasion attacks, such as the ones that use homomorphic character obfuscation, command injection with deformed wildcard characters, UTF7, data URI scheme, and other techniques.
    • Header Inspection (disabled by default): If you enable this, WAF checks all header fields in received requests.
    • Shiro decryption check (disabled by default): If you enable this, WAF uses AES and Base64 to decrypt the rememberMe field in cookies and checks whether this field is attacked, with hundreds of known leaked keys included and checked for.
      NOTE:

      If your website uses Shiro 1.2.4 or earlier, or your website uses Shiro 1.2.5 or later but no AES keys are not configured, it is strongly recommended that you enable Shiro decryption detection to prevent attackers from using leaked keys to construct attacks.
    • Deep Inspection:
    • Header Inspection:
    • Shiro Decryption Check:

    Webshell Detection

    You can enable or disable webshell detection. If you enable it, WAF can protect web applications from web shells that are implanted through upload APIs.

    NOTE:

    HTTP/2 packets do not support web shell detection.

    Protective Action
    You can select the action taken by WAF if a web basic protection rule is triggered.
    • Log only (default): WAF logs the request that triggers the rule but does not block it.
    • Block: WAF logs and blocks the request that triggers the rule.

      Before changing the protective action to block, view the historical logs and confirm that no normal requests trigger the protection rule.

      If the protective action is set to Block, you can configure a known attack source. Then, WAF will block requests matching the configured IP address, Cookie, or Params for a length of time configured as part of the rule.

    Log only
    Table 2 Protection rule description

    Parameter

    Description

    Rule ID

    The protection rule ID, which is generated automatically.

    Rule Description

    Details of attacks the protection rule is configured for.

    CVE ID

    Common Vulnerabilities & Exposures (CVE) ID, which corresponds to the protection rule. For non-CVE vulnerabilities, a double dash (--) is displayed.

    Risk Severity

    Risk severity of a vulnerability. The value can be High, Medium, or Low.

    Application Type

    The application type the protection rule is used for. For details about applications types WAF can protect, see Application Types WAF Can Protect.

    Protection Type

    The type of the protection rule. WAF can discover SQL injection, command injection, XSS attacks, XML external entity (XXE) injection, Expression Language (EL) Injection, SSRF, local file inclusion, remote file inclusion, website Trojans, malicious crawlers, session fixation attacks, deserialization vulnerabilities, remote command execution, information leakage, DoS attacks, source code/data leakage.

    After the preceding configurations are complete, you can simulate SQL injection attacks to verify the protection effect. For details, see Configuration Example - Blocking SQL Injection Attacks in 4.

Configuration Example - Blocking SQL Injection Attacks

The following example shows how to configure WAF rules to protect domain name www.example.com from SQL injection attacks.

  1. Click the Basic Web Protection configuration box and ensure that the basic web protection rules are enabled.

    : enabled.

  2. Enable General Check in Basic Web Protection and set the protection mode to Block.

    Figure 3 Enabling General Check

  3. Enable WAF basic web protection.

    Figure 4 Enabling WAF basic web protection

  4. Clear the browser cache and enter a simulated SQL injection (for example, http://www.example.com?id=' or 1=1) in the address box.

    WAF blocks the access request. Figure 5 shows an example block page.

    Figure 5 Block page

  5. Go to the WAF console. In the navigation pane on the left, choose Events. View the event on the Events page.
Parent Topic: Configuring Protection Rules