Sicherheit

Die Sicherheit-Seite eines Site-Keys entscheidet, wie hart die Aufgabe ist und welche Anfragen sie erreichen dürfen. Die Voreinstellungen sind eine vernünftige Mitte; auf dieser Seite geht es darum, wann du von ihnen abweichst und in welche Richtung.

Starte hier

Die meisten Seiten sollten die Voreinstellungen in Ruhe lassen. Greif zu den Reglern unten, wenn du einen Grund hast:

• Du bist unter aktivem Missbrauch, oder das Formular ist hochwertig (Anmeldungen, Zahlungen, Passwort-Reset): dreh den Schutz hoch. Erhöh Schwierigkeit, erhöh Verschleierungsstufe und schalt Automatisierte Browser blockieren ein. Du tauschst etwas Besucher-Rechenleistung und etwas Server-CPU gegen eine viel höhere Mauer.
• Tempo und Conversion zählen am meisten, und das Risiko ist niedrig (eine Newsletter-Box auf einer Marketing-Seite): halt den Schutz leicht. Lass Schwierigkeit niedrig und Challenges pro Anfrage auf 1, sodass die Aufgabe auf einem billigen Smartphone federleicht ist.

Der Rest dieser Seite ist jeder Regler und in welche Richtung du ihn drehst.

Ein Spiel verlangen

Die stärkste Kontrolle hier ist, einen Besucher zum Spielen eines Spiels zu zwingen, um durchzukommen, nicht nur die stille Hintergrundprüfung zu lösen. Schalt Ein Spiel zur Verifizierung verlangen ein, hier auf der Sicherheit-Seite, und jeder Besucher muss eines der auf diesem Key registrierten Spiele lösen. Der Server wählt, welches Spiel jeder Besucher bekommt, sodass es nicht übersprungen oder getauscht werden kann.

Du registrierst die Spiele, die ein Key nutzen darf, und dort erklärt sich auch das Gate in voller Länge, auf der Spiele und das Spiel-Gate-Seite des Keys. Du kannst das Gate nicht einschalten, bevor mindestens ein Spiel registriert ist. Es aus zu lassen ist die weniger sichere Wahl: Der Key kann passiert werden, ohne ein Spiel zu spielen.

Proof of Work: Schwierigkeit und Challenges pro Anfrage

Proof of Work lässt den Browser ein kleines Rätsel lösen, sodass Missbrauch im großen Maßstab teuer wird (siehe Proof of Work).

• Schwierigkeit (1 bis 8) setzt, wie hart jedes Rätsel ist. Höher kostet einen Angreifer mehr, kostet aber auch das Gerät des Besuchers mehr, was günstige Smartphones am oberen Ende des Bereichs spüren. Fang beim Standard an und erhöh sie nur, wenn du tatsächlich Missbrauch siehst.
• Challenges pro Anfrage (1 bis 500) verlangt mehrere Lösungen auf einmal und vervielfacht die Kosten. Lass es auf 1, außer du hast einen bestimmten Grund, mehr draufzulegen.

Der Browser löst diese Rätsel in einem Web Worker, also muss die Content-Security-Policy deiner Seite blob: für Worker erlauben (worker-src blob:); diese eine ist Pflicht. 'wasm-unsafe-eval' in script-src zu erlauben lässt den Löser zusätzlich als schnelles WebAssembly laufen, aber das ist optional: ohne fällt der Löser auf eine langsamere reine JavaScript-Implementierung im selben Worker zurück, und die Verifizierung funktioniert weiter. Sieh dir Spiel-Sandboxing für die vollständige Host-Seiten-Policy an.

Instrumentierung: Verschleierungsstufe und Automatisierte Browser blockieren

Instrumentierung führt ein kleines Programm im Browser des Besuchers aus, um zu prüfen, dass ein echter Browser, kein Skript, die Aufgabe gelöst hat (siehe Instrumentierung). Sie ist standardmäßig an und ist die einzige Schicht, die einen echten Browser von einem automatisierten unterscheidet.

• Instrumentierung kann pro Key ausgeschaltet werden. Lass sie für fast jede Seite an. Schalt sie nur aus, wenn die Seite, die dein Widget einbettet, eine Content-Security-Policy fährt, die 'unsafe-eval' nicht erlauben kann (das Instrumentierungsprogramm braucht es, siehe unten). Mit ihr aus kann der Key keine automatisierten Browser mehr erkennen, obwohl Proof of Work und jedes verlangte Spiel weiterlaufen, und die zwei Einstellungen unten greifen nicht mehr.
• Verschleierungsstufe (1 bis 10) ist, wie schwer das In-Browser-Programm zu reverse-engineeren ist. Höher ist stärker, nutzt aber mehr Server-CPU. Der Standard passt für die meisten Seiten; erhöh ihn, wenn du das häufige, gezielte Ziel eines Angreifers bist.
• Automatisierte Browser blockieren lehnt erkannte Headless- und WebDriver-Clients rundheraus ab. Schalt es ein, wenn keine legitime Automatisierung je dein Formular berührt. Lass es aus, wenn du legitime Bots erwartest (dein eigenes Monitoring, Partner-Integrationen, Accessibility-Tools), weil es die ebenfalls blockiert.

Content-Security-Policy

Das Instrumentierungsprogramm führt eval im Browser des Besuchers aus, also muss die Seite, die dein Widget einbettet, 'unsafe-eval' in ihrem script-src erlauben. Das ist die eine harte CSP-Anforderung und sie hat keinen Fallback: ist 'unsafe-eval' blockiert, läuft die Verifizierung ins Timeout und die Browser-Konsole zeigt [cap] Instrumentation failed. Du hast zwei Optionen: 'unsafe-eval' auf den Seiten erlauben, die das Widget hosten, oder Instrumentierung ausschalten (oben), um die Anforderung zu entfernen. Die vollständige Liste dessen, was die CSP einer Host-Seite braucht, steht auf Spiel-Sandboxing.

Erforderliche Header

Du kannst verlangen, dass jede Anfrage einen bestimmten Header trägt. Die meisten Seiten brauchen das nicht; es ist nützlich, wenn dein eigener Client immer einen Header sendet, an dem du gaten kannst, als billiger zusätzlicher Filter.

Was du nicht verlangen kannst, sind die Header, die Caputchin aus Datenschutzgründen entfernt, bevor eine Anfrage je die Verifizierung erreicht. Sie identifizieren den Besucher, und Caputchins Haltung ist, keine Daten pro Besucher zu erfassen, also lässt es sie an der Plattformgrenze fallen:

Einen davon zu verlangen würde jede Anfrage blockieren, weil er nie ankommt, also lehnt die Plattform diese Konfiguration ab, statt dich den Key bricken zu lassen.

Rate-Limit und CORS-Origins

• Max. Anfragen pro Sekunde deckelt, wie schnell der Key Anfragen annimmt. Erhöh es, wenn du wirklich viel Traffic hast; senk es, um einen Key zu drosseln, der gehämmert wird.
• CORS-Origins ist deine Origin-Allowlist, serverseitig durchgesetzt, noch bevor das Rätsel läuft. Lass sie leer, solange du von localhost testest; bevor du live gehst, füg deine echten Origins hinzu, damit nur deine eigene Seite den Key nutzen kann.

Siehe auch

• Spiele und das Spiel-Gate, um Spiele zu registrieren und eines zur Verifizierung zu verlangen.
• Site-Keys für den Rest eines Keys.
• Statistik und Sessions, um zu sehen, ob deine Einstellungen den richtigen Traffic stoppen.