After you set up Web Application Firewall (WAF) for a website, you can enable data risk control to protect the website. Data risk control helps you protect crucial website services, such as registrations, logons, activities, and forums, against fraud. You can customize data risk control rules based on your actual requirements.
- A Web Application Firewall instance is available. For more information, see Activate a WAF instance.
- The website is associated with the Web Application Firewall instance. For more information, see Add domain names.
- If the billing method of the instance is subscription, the edition of the instance must be Business or Enterprise.
Data risk control is based on Alibaba Cloud big data. It uses industry-leading engines for risk decision-making and integrates with human-machine identification technologies to protect crucial services in different scenarios against fraud. To use data risk control, set up WAF for your website. No further configurations are required on the server or client side.
Data risk control is suitable in a wide array of scenarios, including but not limited to: malicious registrations, SMS verification code abuse, credential stuffing, brute-force attacks, fraud in flash sales, second kills, bargain manipulation, red envelope lucky draws, ticket snapping by using bots, vote rigging, and spam.
For details about scenarios and protection effects of data risk control, see Examples.
- Static web pages that can be directly accessed through its URL by visitors, such as
HTML details page, shared pages, website homepages, and documents. Web pages that
have adopted redirection methods such as direct modifications of
location.href, and uses of
window.openand anchor tags.
- Web pages where you can rewrite service code and submit requests by using request methods or custom methods, such as submitting forms, rewriting XMLHttpRequest (XHR), and sending custom Ajax requests.
- Requests in the service code contain hooks.
We recommend that after you enable data risk control, choose the detection mode and use data risk control together with real-time log analysis to run a compatibility test. For more information, see Real-time log analysis.
If incompatibility occurs, use Alibaba Cloud Human-Machine Validation together with WAF to protect your websites.
To protect native applications, we recommend that you use the Anti-Bot SDK. For more information, see Configure application protection.
- Log on to the Web Application Firewall console.
- In the top navigation bar, select the resource group to which the instance belongs and the region, Mainland China or International, in which the instance is deployed.
- In the left-side navigation pane, choose .
- In the upper part of the Website Protection page, select the domain name for which you want to configure the whitelist.
- Click the Bot Management tab and find the Data Risk Control section. Set the following parameters and click Settings.
- Strict Interception: If WAF determines that the workloads are under attack, visitors are required to pass strict two-factor authentication.
- Block: If WAF determines that the workloads are under attack, visitors are required to pass two-factor authentication.
- Warn: If WAF determines that the workloads are under attack, requests are forwarded to
your website but relevant events are recorded. You can view detailed information in
- Add a data risk control request.
A newly added request takes effect after 10 minutes. You can view newly added requests in the request list, and modify or delete requests.
- On the Data Risk Control page, click the Protection Request tab, and then click Add Protection Request.
- In the Add Protection Request dialog box, enter the URL that you want to protect in the Protection Request URL field.
For more information, see What is a protected URL in a protection request.
- Click Confirm.
After data risk control is enabled, you can use the logs feature provided by WAF to monitor the protection status. For more information, see View protection results.
What is a protected URL in a protection request
A protected URL in a protection request is the endpoint where operations are performed
on a service. It is not the URL of the web page. As shown in the following figure,
the URL of the registration page is
www.abc.com/new_user. The endpoint where you can obtain verification codes is
www.abc.com/getsmscode, and the endpoint where you can register is
In this example, you need to add a protection request to protect the endpoints
www.abc.com/register.do, respectively. WAF protects these URLs from SMS message abuse and malicious registrations.
If you set the protected URL to
www.abc.com/new_user, general visitors are also required to pass CAPTCHA verification, which may adversely
affect the user experience.
- The protected URL must be specific. Fuzzy match is not supported.
For example, if you set the protected URL to
www.test.com/test, data risk control only filters request sent to this URL. Data risk control does not filter requests sent to the sub-directories of this URL.
- Data risk control only protects website directories.
For example, if you set the protected URL to
www.abc.com/book/*, data risk control filters requests sent to all pages under
www.abc.com/book. We recommend that you do not set data risk control to monitor the entire website. If you set the protected URL to
www.abc.com/*, general visitors need to pass CAPTCHA verification to visit the website homepage. This adversely affects the user experience.
- Requests sent to a protected URL always trigger CAPTCHA verification. Make sure that the protected URL is not directly requested by general visitors in normal cases. Otherwise, general visitors must pass multiple layers of verification before they can visit the URL.
- Data risk control does not support API calls. API calls are directly initiated machine actions and cannot pass the CAPTCHA verification of data risk control. However, if an API operation is called by general visitors clicking a button on a page, you can implement data risk control.
View protection results
You can use the logs feature provided by WAF to monitor the protection status and view blocked requests.
- Allowed requests
The following figure shows a request that has passed data risk control verification. The URL of a request from a general visitor that has passed data risk control verification contains a parameter that starts with u_a. This request is forwarded to the origin server by WAF and the origin server returns a response to the visitor.
- Blocked requests
The following figure shows a request that has been blocked by data risk control. Typically, a request directly sent to the URL of a service does not start with u_a, or starts with a forged User-Agent parameter. This type of request is blocked by WAF and the origin server does return any response.
After you enable the logs feature, you can navigate to Log search.and set the endpoints to be protected by data risk control. This feature helps you monitor the status of data risk control and records blocked requests. For more information, see
User Tom has a website and the website domain is
www.abc.com. General visitors can register as website members at
www.abc.com/register.html. User Tom noticed that attackers can use malicious scripts to submit registration
requests. These accounts are used to participate in prize draws held by the website.
The registration requests are highly similar to normal requests, and the request rate
is maintained at a normal level. Compared to traditional HTTP flood attacks, this
type of malicious request is difficult to identify.
User Tom set up WAF for the website and enabled data risk control for the domain
www.abc.com. The URL of the most crucial registration service is
www.abc.com/register.html. Therefore, User Tom set the protected URL to this URL.
into all web pages of the website to monitor and analyze the behaviors of each visitor
www.abc.com, including the homepage. Data risk control then determines whether a visitor behavior
is normal. Data risk control also determines whether a source IP address is malicious
based on data provided by the Alibaba Cloud big data reputation library.
www.abc.com/register.html, WAF determines whether the visitor is a potential attacker based on the visitor behavioral data generated from the visitor visiting the website to submitting the registration request. For example, if a visitor directly submits a registration request without performing other operations first, the request is potentially malicious.
- If data risk control determines that the request is from a general visitor based on previous visitor behaviors, the visitor can register accounts without verification.
- If data risk identifies a request as potentially malicious, or the source IP address
has a record of sending malicious requests, CAPTCHA is triggered to verify the identity
of the visitor. Only visitors that pass the verification can register accounts.
- If CAPTCHA verification captures suspicious visitor behaviors, such as using scripts to simulate real visitor behaviors to pass CAPTCHA verification, data risk control requires two-factor authentication to verify the visitor identity until the visitor passes verification and is identified as a general visitor.
- If the visitor fails the verification, data risk control blocks the request.
During this process, data risk control is enabled for the entire website (
analyze visitor behaviors. However, protection and verification are only enabled for
www.abc.com/register.html where visitors submit registration requests. Data risk control is triggered only
after a registration request is submitted.