Help Center/ Web Application Firewall/ User Guide/ Configuring Protection Policies/ Configuring Basic Web Protection to Defend Against Common Web Attacks
Updated on 2024-11-19 GMT+08:00

Configuring Basic Web Protection to Defend Against Common Web Attacks

After this function is enabled, WAF can defend against common web attacks, such as SQL injections, XSS, remote overflow vulnerabilities, file inclusions, Bash vulnerabilities, remote command execution, directory traversal, sensitive file access, and command/code injections. You can also enable other checks in basic web protection, such as web shell detection, deep inspection against evasion attacks, and header inspection.

If you have enabled enterprise projects, ensure that you have all operation permissions for the project where your WAF instance locates. Then, you can select the project from the Enterprise Project drop-down list and configure protection policies for the domain names in the project.

Prerequisites

Constraints

  • Basic web protection has two modes: Block and Log only.
  • If you select Block for Basic Web Protection, you can configure access control criteria for a known attack source. WAF will block requests matching the configured IP address, cookie, or params for a length of time configured as part of the rule.
  • Currently, the deep inspection and header inspection are supported in CN-Hong Kong, CN North-Beijing1, CN North-Beijing4, CN East-Shanghai1, CN East-Shanghai2, CN South-Guangzhou, CN South-Shenzhen, CN Southwest-Guiyang1, and AP-Bangkok.
  • Currently, Shiro decryption check is supported in CN North-Beijing4 and CN-Hong Kong.

Enabling Basic Web Protection Rules

  1. Log in to the management console.
  2. Click in the upper left corner of the management console and select a region or project.
  3. Click in the upper left corner and choose Web Application Firewall under Security & Compliance.
  4. In the navigation pane on the left, choose Policies.
  5. Click the name of the target policy to go to the protection configuration page.
  6. Click the Basic Web Protection configuration area and toggle it on or off if needed.

    • : enabled.
    • : disabled.

  7. Configure a basic web protection rule, as shown in Figure 1.

    Figure 1 Rule Configuration
    1. 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.
    2. Select a protection level.

      There are three protection levels: Default rule set (loose), Default rule set (medium), and Default rule set (tight). Default rule set (medium) is selected by default.

      Table 1 Protection levels

      Protection Level

      Description

      Default rule set (loose)

      WAF only blocks the requests with obvious attack signatures.

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

      Default rule set (medium)

      This one is selected by default. It meets a majority of web protection requirements.

      Default rule set (tight)

      At this level, WAF provides the finest granular protection and can intercept 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.

      Click View Rule Set Details to view details about all basic web protection rules. You can know which rules are loose, which are medium, and which are tight.

      Click to search for a rule by CVE ID, Risk Severity, Application Type, or Protection Type.

      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

      The severity of the vulnerability, including:

      • High
      • Medium
      • 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.

    3. Enable the check items in Detection Scope based on service requirements.
      Table 3 Check item description

      Type

      Description

      Deep Inspection

      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.

      NOTE:

      If you enable Deep Inspection, WAF detects and defends against evasion attacks in depth.

      Header Inspection

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

      NOTE:

      If you enable this function, WAF checks all header fields in the requests.

      Shiro Decryption Check

      This function is disabled by default. After this function is enabled, WAF uses AES and Base64 to decrypt the rememberMe field in cookies and checks whether this field is attacked. There are 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.

    4. Configure Webshell Detection.

      If you enable Webshell Detection, WAF detects web page Trojan horses inserted through the upload interface.

  8. Configure a protective action. You can select:

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.
  • 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.

Protection Effect

If General Check is enabled and Mode is set to Block for your domain name, to verify WAF is protecting your website (www.example.com) against general check items:

  1. Clear the browser cache and enter the domain name in the address bar to check whether the website is accessible.

    • If the website is inaccessible, connect the website domain name to WAF by following the instructions in Website Settings.
    • If the website is accessible, go to 2.

  2. Clear the browser cache and enter http://www.example.com?id=1%27%20or%201=1 in the address box of the browser to simulate an SQL injection attack.
  3. Return to the WAF console. In the navigation pane, click Events. On the displayed page, view the event log.

Example - Blocking SQL Injection Attacks

If domain name www.example.com has been connected to WAF, perform the following steps to verify that WAF can block SQL injection attacks.

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

    Figure 2 Enabling General Check

  2. Enable WAF basic web protection.

    Figure 3 Basic Web Protection configuration area

  3. 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 4 shows an example block page.

    Figure 4 Block page

  4. Go to the WAF console. In the navigation pane on the left, choose Events. View the event on the Events page.