Proteggere un checkout

Il card testing è uno script che prova carte rubate con piccoli pagamenti, uno dopo l'altro, per scoprire quali funzionano ancora. Di solito lo script non carica mai la tua pagina. Il tag non viene mai eseguito, quindi la decisione non ha alcun segnale da un browser, e la sua classe è unknown, che passa. Un segnale assente non è mai una prova di un bot, quindi Bot Protection non lo chiama così. Sulle azioni a cui punta uno script del genere, chiedi invece la prova di una visita reale: il token del tag.

Cosa fa requireToken

Con "require_token": true nella chiamata (l'opzione requireToken degli SDK, in Go RequireToken), l'azione prosegue solo con un token valido ottenuto dal tag in quel browser. Senza, la risposta è challenge con token_required true, qualunque sia la classe; la classe in sé non cambia. L'invio del modulo spende il token, una volta per sessione e per percorso ogni ora; fino a tre tentativi entro due minuti sono lo stesso tentativo, quindi una carta rifiutata e una seconda carta passano comunque. Un caricamento di pagina (GET, HEAD) non spende token, e gli SDK inviano l'opzione solo con le azioni. Le regole complete: un'azione che richiede il tag.

Metti il tag sulla pagina da cui parte ogni azione: la pagina di checkout, quella di accesso, quella di registrazione. Il tag

Quali rotte

• Pagamento: l'invio che addebita la carta o conferma l'ordine, e ogni invio che aggiunge una carta o usa una carta regalo. Il card testing.
• Accesso: l'invio che controlla la password. Il credential stuffing.
• Registrazione: l'invio che crea l'account. Gli account falsi.

Lasciala fuori dalle rotte a cui nessuna tua pagina porta: i webhook del tuo fornitore di pagamenti, l'API della tua app mobile, il server di un partner. Lì non gira nessun tag, quindi ogni richiesta riceverebbe una sfida.

Nel tuo codice

Ogni scheda la aggiunge alla chiamata che la guida del suo framework imposta. Node e Go usano l'opzione del file client che Korzen fornisce; gli altri inviano il campo nel corpo della chiamata.

// Express, with korzen.js as the Express guide sets it up
const guard = protect({ client: korzen, ip: (_get, req) => req.ip, requireToken: true });

app.get("/checkout", guard, showCheckout); // the page: a page load spends no token
app.post("/checkout", guard, placeOrder); // the action: it needs the tag's token

// Next.js, Hono or any handler of a Web Request
export const POST = withKorzen(placeOrder, { client, ip: ipFrom.vercel, requireToken: true });

mux.Handle("POST /checkout", bot.Protect(http.HandlerFunc(placeOrder), korzen.Options{
	IP:           korzen.RemoteIP,
	RequireToken: true, // the action needs the tag's token
}))

# In decide() of the Django and Flask or FastAPI guide: one more field in the body.
json={
    # ...the fields the guide sends
    "path": path,
    "method": "POST",
    "require_token": True,  # on payment, login and sign-up
},

// In decide() of the PHP or Laravel guide: one more field in the body.
'path' => $path,
'method' => 'POST',
'require_token' => true, // on payment, login and sign-up

// In decide() of the Spring Boot guide: one more field in the body.
body.put("path", path);
body.put("method", "POST");
body.put("require_token", true); // on payment, login and sign-up

// In Decide() of the ASP.NET Core guide: one more field in the body.
["path"] = path,
["method"] = "POST",
["require_token"] = true, // on payment, login and sign-up

# In decide of the Rails guide: one more field in the body.
path: path,
method: "POST",
require_token: true # on payment, login and sign-up

# wrangler.toml: the paths whose actions need the tag's token, by commas;
# one ending in * is a prefix.
[vars]
KORZEN_REQUIRE_TOKEN = "/checkout,/login,/signup"

Quando la stessa funzione chiede per tutte le azioni, lasciale la scelta: passa true dagli handler di pagamento, accesso e registrazione e false dagli altri. Un campo scritto male, come requireToken nel corpo, viene rifiutato con 400 e lascia passare il visitatore, come ogni errore: controlla le prime risposte.

Prima la modalità monitor

Attivala mentre l'account è in modalità monitor. L'action di ogni risposta resta allow, quindi nessuno viene fermato; un'azione arrivata senza token risponde intended_action challenge con token_required true. Segui due numeri per qualche giorno:

• le decisioni su queste rotte con token_required true, nelle risposte che il tuo server registra;
• la quota Senza token nello stato dell'integrazione, nella pagina Configurazione. Una quota alta lì indica di solito una pagina senza tag che porta all'azione, o un modulo inviato prima che il tag sia stato eseguito: correggi prima questo.

Quello che resta sono per lo più script, e alcune persone il cui browser non esegue il tag (sotto). Attiva la modalità blocco quando quella quota ti sembra accettabile. Modalità monitor e modalità blocco

Le azioni di ogni classe

I valori predefiniti vanno bene per un checkout. L'azione della classe e il token sono separati: con un token valido, l'azione è quella della classe; senza, è almeno challenge.

Con l'esca attivata per bot e bot_high nella pagina Configurazione, gli SDK rispondono da soli a un'azione con esca, con qualcosa che sembra un successo, così lo script non impara nulla. Una risposta esca

Dopo il pagamento, invia l'esito del tuo fornitore di pagamenti come feedback: un chargeback o una frode confermata abbassano le prossime decisioni per quel browser, un buon cliente le alza.

Chi ferma

Un visitatore il cui browser non esegue il tag non ha un token: un blocco della pubblicità o un'estensione per la privacy che lo blocca, un filtro DNS che blocca l'host dell'API di Bot Protection, JavaScript disattivato. Su una rotta con require_token, in modalità blocco, quel visitatore riceve una sfida sull'azione. La nostra pagina di sfida chiede una piccola prova di lavoro e che il nostro tag giri lì. Con JavaScript disattivato non c'è modo di passare, e un filtro DNS che blocca il nostro host blocca anche la pagina. Quella persona non può pagare, a meno che tu non le dia un'altra strada.

• Inviala sulle rotte dove uno script ti costa più di una persona fermata: pagamento, accesso, registrazione. Mai su tutte le rotte.
• Leggi la quota in modalità monitor prima di attivare la modalità blocco, come sopra.
• Sotto challenge, offri una strada che non richieda il nostro tag, se ne hai una: 3-D Secure, un codice via email o telefono, un contatto del supporto. L'hook onChallenge degli SDK la esegue al posto del reindirizzamento.

Quando Bot Protection è lento o non risponde, il tuo server lascia passare il visitatore, con o senza token: la chiamata è fail-open.