Einen Checkout schützen

Kartentests (Card Testing) sind ein Skript, das gestohlene Karten mit kleinen Zahlungen nacheinander ausprobiert, um herauszufinden, welche noch funktionieren. Meist lädt das Skript Ihre Seite nie. Der Tag läuft nie, also hat die Entscheidung kein Signal von einem Browser, und ihre Klasse ist unknown, die durchgelassen wird. Ein fehlendes Signal ist nie ein Beleg für einen Bot, also nennt Bot Protection es auch nicht so. Verlangen Sie bei den Aktionen, auf die ein solches Skript zielt, stattdessen den Nachweis eines echten Besuchs: das Token des Tags.

Was requireToken bewirkt

Mit "require_token": true im Aufruf (die Option requireToken der SDKs, in Go RequireToken) geht die Aktion nur mit einem gültigen Token weiter, das der Tag in diesem Browser erhalten hat. Ohne Token ist die Antwort challenge mit token_required true, gleich welche Klasse; die Klasse selbst ändert sich nicht. Das Absenden des Formulars verbraucht das Token, einmal pro Sitzung und Pfad pro Stunde; bis zu drei Versuche innerhalb von zwei Minuten sind derselbe Versuch, also gehen eine abgelehnte Karte und eine zweite Karte weiterhin durch. Ein Seitenaufruf (GET, HEAD) verbraucht kein Token, und die SDKs senden die Option nur bei Aktionen. Die Regeln im Einzelnen: Eine Aktion, die den Tag braucht.

Setzen Sie den Tag auf die Seite, auf der jede Aktion beginnt: die Checkout-Seite, die Login-Seite, die Registrierungsseite. Der Tag

Welche Routen

• Zahlung: das Absenden, das die Karte belastet oder die Bestellung aufgibt, und jedes, das eine Karte hinzufügt oder einen Gutschein einlöst. Kartentests.
• Login: das Absenden, das das Passwort prüft. Credential Stuffing.
• Registrierung: das Absenden, das das Konto anlegt. Fake-Accounts.

Lassen Sie es bei Routen weg, zu denen keine Ihrer Seiten führt: die Webhooks Ihres Zahlungsanbieters, die API Ihrer mobilen App, der Server eines Partners. Dort läuft kein Tag, also bekäme jede Anfrage eine Challenge.

In Ihrem Code

Jeder Tab ergänzt den Aufruf, den die Anleitung seines Frameworks einrichtet. Node und Go nutzen die Option der Client-Datei, die Korzen bereitstellt; die anderen senden das Feld im Body des Aufrufs.

// 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"

Wenn dieselbe Funktion für jede Aktion fragt, geben Sie ihr die Wahl: Übergeben Sie true aus den Handlern für Zahlung, Login und Registrierung und false aus den übrigen. Ein falsch geschriebenes Feld, etwa requireToken im Body, wird mit 400 abgelehnt und lässt den Besucher durch, wie jeder Fehler: Prüfen Sie die ersten Antworten.

Zuerst der Monitor-Modus

Schalten Sie es ein, solange das Konto im Monitor-Modus ist. Die action jeder Antwort bleibt allow, also wird niemand aufgehalten; eine Aktion, die ohne Token kam, antwortet mit intended_action challenge und token_required true. Beobachten Sie einige Tage lang zwei Zahlen:

• die Entscheidungen auf diesen Routen mit token_required true, in den Antworten, die Ihr Server protokolliert;
• den Anteil Ohne Token im Integrationsstatus auf der Seite Einrichtung. Ein hoher Anteil dort bedeutet meist eine Seite ohne Tag, die zur Aktion führt, oder ein Formular, das abgeschickt wird, bevor der Tag gelaufen ist: Beheben Sie das zuerst.

Was übrig bleibt, sind meist Skripte und einige Menschen, deren Browser den Tag nicht ausführt (unten). Schalten Sie den Block-Modus ein, wenn Sie diesen Anteil akzeptieren. Monitor- und Block-Modus

Die Aktionen jeder Klasse

Die Standardwerte passen zu einem Checkout. Die Aktion der Klasse und das Token sind getrennt: Mit gültigem Token ist die Aktion die der Klasse; ohne ist sie mindestens challenge.

Ist der Köder auf der Seite Einrichtung für bot und bot_high eingeschaltet, beantworten die SDKs eine geköderte Aktion von selbst mit etwas, das wie ein Erfolg aussieht, damit das Skript nichts lernt. Eine Köder-Antwort

Senden Sie nach der Zahlung das Ergebnis Ihres Zahlungsanbieters als Feedback: Eine Rückbuchung (Chargeback) oder ein bestätigter Betrug senkt die nächsten Entscheidungen für diesen Browser, ein guter Kunde hebt sie an.

Wen es aufhält

Ein Besucher, dessen Browser den Tag nicht ausführt, hat kein Token: ein Werbeblocker oder eine Datenschutz-Erweiterung, die ihn blockiert, ein DNS-Filter, der den API-Host von Bot Protection blockiert, abgeschaltetes JavaScript. Auf einer Route mit require_token bekommt dieser Besucher im Block-Modus bei der Aktion eine Challenge. Unsere Challenge-Seite verlangt einen kleinen Proof of Work und dass unser Tag dort läuft. Ohne JavaScript gibt es keinen Weg vorbei, und ein DNS-Filter, der unseren Host blockiert, blockiert auch die Seite. Diese Person kann nicht bezahlen, es sei denn, Sie bieten ihr einen anderen Weg.

• Senden Sie es auf den Routen, auf denen ein Skript Sie mehr kostet als ein aufgehaltener Mensch: Zahlung, Login, Registrierung. Nie auf jeder Route.
• Lesen Sie den Anteil im Monitor-Modus, bevor Sie den Block-Modus einschalten, wie oben.
• Bieten Sie unter challenge einen Weg an, der unseren Tag nicht braucht, wenn Sie einen haben: 3-D Secure, einen Code per E-Mail oder Telefon, einen Kontakt zum Support. Der Hook onChallenge der SDKs führt ihn statt der Weiterleitung aus.

Wenn Bot Protection langsam oder nicht erreichbar ist, lässt Ihr Server den Besucher durch, mit oder ohne Token: Der Aufruf ist fail-open.