Block account takeover on login and checkout flows

A fraud or security team in retail, financial services, or gaming sees credential stuffing, fake account creation, and card testing on its login, signup, and checkout endpoints. Those three paths are where an automated client gains the most per request, and where a refused customer costs the most. This page configures Bot Manager on the firewall for those paths only: it scores every request for automation, sends a flagged client on login and signup to a challenge a person can solve, and denies a flagged client on checkout, while WAF filters attacks on the same paths. The result is measured by the share of automated login and checkout attempts blocked, the false-positive rate on real users, and the attack traffic that still reaches the origin.

This use case does not cover general API abuse, which Protect public APIs from abuse covers.

Prerequisites

• An application that serves the site through a connector and a workload. To create them, refer to Applications quickstart.
• A firewall bound to that workload’s deployment, with WAF and Functions turned on in Main Settings › Modules. To bind it, refer to Bind a firewall to a workload, and to turn on WAF, refer to Set a firewall’s main settings.
• Bot Manager enabled on the account, or Bot Manager Lite installed from Azion Marketplace. To install Bot Manager Lite, refer to Install Bot Manager Lite.
• ALTCHA instanced on the same firewall, with its rule matching /login, /signup, /az-request-verify, and /az-request-captcha, created before the Bot Manager rules on this page. ALTCHA serves the challenge Bot Manager redirects a flagged client to. To set it up, follow Protect a route with an ALTCHA challenge on this firewall, with /login and /signup as the protected routes, and leave out its application rule: on this page, the redirect action of Bot Manager sends only flagged clients to the challenge.
• A personal token, for the API tabs. To create one, refer to Personal tokens.
• The values of your site. This page uses www.example.com for the domain, /login, /signup, and /checkout for the three paths, and auth as the prefix of every object it creates. Replace each value with yours in every step.

Required products

Reference architecture

This page builds the Bot-scoring perimeter for authentication flows: firewall rules that scope Bot Manager to the login, signup, and checkout paths, where the score decides whether a request passes, is challenged, or is denied.

Read the diagram at the path split. The firewall’s rules hand only the three sensitive paths to WAF and Bot Manager, so every other page is served without a score. On /login, /signup, and /checkout, the score of the instance that path runs sends each request one of three ways: through to the application, to the ALTCHA challenge a person can solve, or to a refusal. One instance per kind of path lets each run its own threshold and action.

Dataflow

1. A request reaches the firewall bound to the workload. The ALTCHA rule runs first, so a client that already solved a challenge carries a session that ALTCHA validates.
2. The WAF rule scores requests to the three paths for attack payloads, such as an injection in a form field.
3. On /login and /signup, the auth-login-challenge instance scores the request. A score at its threshold redirects the client to the ALTCHA challenge. A person who solves it continues, and later requests pass without a new challenge.
4. On /checkout, the auth-checkout-deny instance scores the request. A score at its threshold receives 403, because a checkout request that a script sends has no person to answer a challenge.
5. A request below the threshold reaches the application, and from it the identity system or the payment flow.
6. Each instance writes a report line per request, which Real-Time Events holds and Data Stream sends to the fraud team’s tools.

Components

• firewall: the Platform Resource whose path-scoped rules decide which requests Bot Manager and WAF see. One rule per kind of path lets each run its own threshold and action.
• Bot Manager: scores each request for automation and runs the action its instance sets once the score reaches the threshold. Its actions include redirect, which sends a client to a challenge, and deny, which refuses it with 403.
• WAF: scores the same paths for attack payloads, such as injections in login and checkout form fields.
• Functions: runs the challenge, here ALTCHA from Azion Marketplace, ahead of Bot Manager, and any check the team writes for the firewall execution environment on the same paths.
• Data Stream: sends the Functions data source, which carries the Bot Manager report lines, to an endpoint the fraud team reads.
• SIEM: the integration where the fraud team correlates Bot Manager’s decisions with its own signals.
• Real-Time Events: holds each report line, with the score and the rules behind it, for the investigation of one decision.

Configure the observation window

Before any instance refuses a request, one instance in observation mode scores the three paths and refuses nothing: action is allow, and internal_logs is 2, so every request writes a report line. Run it for 24 to 72 hours, long enough to cover peak hours, weekly crawlers, and overnight jobs. The lines are the only description of how your own customers score, and the thresholds in the next section come from them. threshold is 10, the stricter of the two starting points below, so the classified label shows which requests that threshold would act on. log_tag is auth-observe, so each line names this instance.

Create the instance and the rule as Run Bot Manager on selected paths describes, with these values:

• Instance: auth-observe, with these arguments:

  { "threshold": 10, "action": "allow", "internal_logs": 2, "log_tag": "auth-observe" }

• Rule: auth - observe authentication paths, with one block of criteria that names the three paths, joined by or: Request Uri starts with /login, /signup, or /checkout. In the API, the block is:

  JSON

  01[

  02 { "variable": "${request_uri}", "conditional": "if", "operator": "starts_with", "argument": "/login" },

  03 { "variable": "${request_uri}", "conditional": "or", "operator": "starts_with", "argument": "/signup" },

  04 { "variable": "${request_uri}", "conditional": "or", "operator": "starts_with", "argument": "/checkout" }

  05]

• Behavior: Run Function with auth-observe.

Every request to the three paths is scored and served, and each one writes a line tagged auth-observe. Read score and matched_rules on requests you recognize as customers, because classified depends on the threshold in force. For the procedure, refer to Run Bot Manager in observation mode.

Configure challenge and deny by path

One instance carries one threshold and one action, so the two kinds of path take an instance each. The thresholds start where Firewall best practices start them for these paths, and the observation window moves them: lower while automated clients pass, higher while customers you recognize are flagged.

redirect_to is /az-request-verify, the path where ALTCHA serves its challenge. With no valid redirect_to, Bot Manager runs allow instead, so confirm in the report log that the instance redirects. Each instance has its own log_tag, so a refusal can be traced to the path that produced it.

internal_logs stays at 2 on both instances while you verify them, so every request writes a line. Observation mode writes a line for every request, so lower internal_logs once the thresholds hold. An argument change reaches traffic about 105 seconds after it is saved, and a new rule 6 to 10 minutes after.

Configure WAF on the authentication paths

The WAF rule set auth-waf scores requests to the three paths for attack payloads, such as an injection in a login form field. It carries the eight threat families at medium, the level every family starts at, and the rule that applies it starts in Logging. Move it to Blocking once 3 days of Tuning hold no request that should have been served. The rule matches the paths, not the query string, because a login form posts its fields in the body.

Requests to the three paths are scored for attack payloads, and what would be blocked is recorded. To move the rule to Blocking, refer to Switch a rule set to blocking.

Verify the setup

An argument change reaches traffic about 105 seconds after it is saved, and a new rule 6 to 10 minutes after. Repeat each request until the answer holds. Each check reads the report line in the functionConsoleEvents dataset of Real-Time Events, as Read the report log describes.

• Only the three paths are scored. Request the home page and /login:

  Shell

  01curl -s -o /dev/null https://www.example.com/

  02curl -s -o /dev/null https://www.example.com/login

  A report line appears for /login, and none for /.

• A flagged checkout request is denied. Send a request with no user agent, which is what a scripted client sends:

  curl -s -o /dev/null -w '%{http_code}\n' -A "" https://www.example.com/checkout

  When the request’s score reaches 10, the command prints 403, and the line tagged auth-checkout-deny reads "action":"deny". A lower score is served, and the line shows the score it received.

• A flagged login request is challenged. Send the same request to /login:

  curl -s -o /dev/null -w '%{redirect_url}\n' -A "" https://www.example.com/login

  When the score reaches 10, the command prints the address of /az-request-verify, and the line tagged auth-login-challenge reads "action":"redirect". A line that reads allow at a score at the threshold means redirect_to is missing or invalid.

• A person passes the challenge. Open https://www.example.com/login in a browser, from a client the instance flags, and solve the challenge. The login page loads, and later requests pass without a new challenge.

• WAF scores the three paths. Send https://www.example.com/login?q=1%27%20OR%20%271%27%3D%271. In Logging, the page loads. After the switch to Blocking, the request receives 400.

Measuring results

Best practices

• Set each threshold from your own scores. The starting values are documented starting points, not descriptions of your traffic. A threshold inside the customers’ cluster refuses them, and one past the automated cluster acts on nothing. For the reasoning, refer to Set the Bot Manager threshold from your own score distribution.
• Run ALTCHA before Bot Manager. A redirected client comes back to the firewall. When Bot Manager scores the returning request before ALTCHA validates its session, it redirects the client again.
• Write out every argument the instance depends on. Nothing validates the arguments object. A misspelled key such as thresold is stored without an error, and the instance runs its default, which on Bot Manager Lite is deny at 30.
• Read what a rule matched before you disable it. matched_rules names the Bot Manager rules behind each score. Disabling one stops it for every client, so narrow the instance’s paths instead when a rule flags customers on one path.
• Keep a copy of the report lines you own. Real-Time Events keeps an event record for 7 days, and a fraud investigation often looks further back. Send the Functions data source to the fraud team’s endpoint with Debug functions with Data Stream.

Guides in this use case