Een checkout beschermen

Card testing is een script dat gestolen kaarten probeert met kleine betalingen, de een na de ander, om te vinden welke nog werken. Meestal laadt het script je pagina nooit. De tag draait nooit, dus de beslissing heeft geen enkel signaal van een browser, en de klasse is unknown, die wordt doorgelaten. Een ontbrekend signaal is nooit bewijs van een bot, dus Bot Protection noemt het ook geen bot. Vraag bij de acties waar zo'n script op mikt in plaats daarvan het bewijs van een echt bezoek: het token van de tag.

Wat requireToken doet

Met "require_token": true in de call (de optie requireToken van de SDK's, in Go RequireToken) gaat de actie alleen door met een geldig token dat de tag in die browser kreeg. Zonder token is het antwoord challenge met token_required true, welke klasse ook; de klasse zelf verandert niet. Het versturen van het formulier besteedt het token, één keer per sessie en per pad per uur; tot drie pogingen binnen twee minuten zijn dezelfde poging, dus een geweigerde kaart en een tweede kaart komen nog door. Het laden van een pagina (GET, HEAD) besteedt geen token, en de SDK's sturen de optie alleen met acties mee. Alle regels: een actie die de tag nodig heeft.

Zet de tag op de pagina waar elke actie begint: de checkoutpagina, de inlogpagina, de aanmeldpagina. De tag

Welke routes

• Betalen: het versturen dat de kaart belast of de bestelling plaatst, en elk dat een kaart toevoegt of een cadeaukaart inwisselt. Card testing.
• Inloggen: het versturen dat het wachtwoord controleert. Credential stuffing.
• Aanmelden: het versturen dat het account aanmaakt. Nepaccounts.

Laat het weg op routes waar geen pagina van jou naartoe leidt: de webhooks van je betaalprovider, de API van je mobiele app, de server van een partner. Daar draait geen tag, dus elke request zou een uitdaging krijgen.

In je code

Elk tabblad voegt het toe aan de call die de handleiding van dat framework opzet. Node en Go gebruiken de optie van het clientbestand dat Korzen aanbiedt; de andere sturen het veld mee in de body van de call.

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

Als dezelfde functie voor elke actie vraagt, geef haar dan de keuze: geef true mee vanuit de handlers voor betalen, inloggen en aanmelden en false vanuit de rest. Een verkeerd gespeld veld, zoals requireToken in de body, wordt geweigerd met 400 en laat de bezoeker door, zoals elke fout: controleer de eerste antwoorden.

Eerst de monitormodus

Zet het aan terwijl het account in monitormodus staat. De action van elk antwoord blijft allow, dus niemand wordt tegengehouden; een actie die zonder token kwam, antwoordt intended_action challenge met token_required true. Volg een paar dagen twee getallen:

• de beslissingen op deze routes met token_required true, in de antwoorden die je server logt;
• het aandeel Zonder token in de integratiestatus op de pagina Set-up. Een hoog aandeel daar betekent meestal een pagina zonder tag die naar de actie leidt, of een formulier dat verstuurd wordt voordat de tag gedraaid heeft: los dat eerst op.

Wat overblijft zijn vooral scripts, en enkele mensen van wie de browser de tag niet draait (hieronder). Zet de blokkeermodus aan als je dat aandeel accepteert. Monitormodus en blokkeermodus

De acties per klasse

De standaardwaarden passen bij een checkout. De actie van de klasse en het token staan los van elkaar: met een geldig token is de actie die van de klasse; zonder is het minstens challenge.

Met het lokantwoord aangezet voor bot en bot_high op de pagina Set-up, beantwoorden de SDK's zo'n actie zelf met iets wat op succes lijkt, zodat het script niets leert. Een lokantwoord

Stuur na de betaling de uitkomst van je betaalprovider als feedback: een chargeback of bevestigde fraude verlaagt de volgende beslissingen voor die browser, een goede klant verhoogt ze.

Wie het tegenhoudt

Een bezoeker van wie de browser de tag niet draait, heeft geen token: een adblocker of een privacy-extensie die hem blokkeert, een DNS-filter dat de API-host van Bot Protection blokkeert, JavaScript uitgeschakeld. Op een route met require_token krijgt die bezoeker in blokkeermodus een uitdaging bij de actie. Onze uitdagingspagina vraagt een kleine proof of work en dat onze tag daar draait. Zonder JavaScript is er geen weg langs, en een DNS-filter dat onze host blokkeert, blokkeert de pagina ook. Die persoon kan niet betalen, tenzij je hem een andere weg geeft.

• Stuur het mee op de routes waar een script je meer kost dan een tegengehouden mens: betalen, inloggen, aanmelden. Nooit op elke route.
• Lees het aandeel in monitormodus voordat je de blokkeermodus aanzet, zoals hierboven.
• Bied onder challenge een weg die onze tag niet nodig heeft, als je er een hebt: 3-D Secure, een code per e-mail of telefoon, contact met support. De hook onChallenge van de SDK's voert die uit in plaats van de redirect.

Als Bot Protection traag of onbereikbaar is, laat je server de bezoeker door, met of zonder token: de call is fail-open.