Using the deception action

This guide only applies to Next-Gen WAF customers with access to the Next-Gen WAF control panel.

To help defend your web applications from Account Takeover (ATO) attacks (e.g., credential stuffing), you can add rules that use the Deception action type. When the Next-Gen WAF identifies POST requests to login forms that match these rules, the WAF prevents the requests from accessing your origin and returns an invalid credentials page. This response tricks attackers into believing their attack failed due to incorrect credentials, when in reality the WAF actually blocked them. The deception response discourages attackers from continuing their account takeover attempts to save resources and time.

Prerequisites

To use the deception action, be sure you have the following prerequisites in place:

Limitations and considerations

When working with the deception action, keep in mind the following:

  • Advanced rate limiting rules and request rules support the deception action at the site-level (workspace-level) only. Other rule types don't support the deception action.
  • Deception rules only take action on POST requests to login forms where the password field is named password, passwd, pass, or pw.

How it works

Let's say you have a deception rule protecting your web application's login page from POST requests that use known compromised credentials. When the Next-Gen WAF identifies a request that meets the rule's conditions, the WAF:

  • tags the request with the Deception Response signal.
  • obtains the invalid credentials page from your web application.
  • forwards the invalid credentials page to the attacker. This tricks the attacker into thinking that their login attempt failed and that the WAF did not block them.

Examples

The following examples demonstrate how to configure deception rules to prevent ATO attacks. Be aware that values (e.g., paths) used in these examples may not be the same as those used by your particular web application.

Example request rule

This example demonstrates how to configure a request rule that will deceive attackers attempting to use suspected bad bots to log in to a web application.

The request rule requires two conditions:

  • The request must be tagged with the Suspected Bad Bot signal.
  • The path of the request needs to be /login.

HINT: A condition requiring the HTTP method to be POST is not required. The Next-Gen WAF won't take action on matching requests unless the HTTP method is POST.

The rule must have an Action type of Deception and a Deception type of Invalid Login Response.

A request rule designed to deceive attackers attempting to use suspected bad bots to log in.

Example advanced rate limiting rule

This example demonstrates how to configure an advanced rate limiting rule that will deceive attackers attempting to use known compromised credentials to log in to a web application after they exceed a threshold.

The advanced rate limiting rule requires two conditions:

  • The request must be tagged with the Compromised Password signal.
  • The path of the request needs to be /login.

HINT: A condition requiring the HTTP method to be POST is not required. The Next-Gen WAF won't take action on matching requests unless the HTTP method is POST.

The rule must also:

  • set the Client key to IP address (default). Client key specifies how the WAF should identify an individual client.
  • define threshold tracking behavior by setting Threshold signal to the Rate Limit ATO custom signal and leaving the default Threshold and Interval values.
  • define rate limiting behavior by setting Action type to Deception and Deception type to Invalid Login Response.

An advanced rate limiting rule designed to deceive attackers attempting to use compromised credentials to log in.