reCAPTCHA-Firewallrichtlinien – Übersicht

In diesem Dokument finden Sie eine Übersicht über die reCAPTCHA-Firewallrichtlinien.

Eine reCAPTCHA-Firewallrichtlinie besteht aus einer Reihe von Regeln, die anhand von Bedingungsattributen Ihre Website vor Spam und Missbrauch schützen. Jede Regel wird für den eingehenden Traffic ausgewertet. Die Regeln werden in der Reihenfolge ausgewertet, in der sie in der Richtlinie hinzugefügt wurden.

Komponenten der reCAPTCHA-Firewallrichtlinie

Eine reCAPTCHA-Firewallrichtlinienregel besteht aus den folgenden Komponenten:

  • path: Ein URL-Pfad, auf den sich die Firewallrichtlinienregel bezieht. Beispiel: /login
  • condition: eine Richtlinienbedingung. Eine Richtlinienbedingung ist ein CEL-Ausdruck (Common Expression Language), der in einen booleschen Wert aufgelöst werden muss. Beispiel: recaptcha.score >= 0.5.
  • action: Eine Aktion, die Ihr WAF-Anbieter ausführen muss, wenn die Richtlinienbedingung erfüllt ist. Weitere Informationen finden Sie unter Richtlinienaktionen.

Wenn eine eingehende Anfrage mit einer Richtlinienbedingung für den angegebenen Pfad übereinstimmt, lässt Ihr WAF-Anbieter die Anfrage gemäß der angegebenen Aktion zu, blockiert sie oder leitet sie weiter. Standardmäßig ist der Zugriff erlaubt.

Beispiel für eine reCAPTCHA-Firewallrichtlinie

Die folgende Beispiel-reCAPTCHA-Firewallrichtlinie enthält eine Regel, die auf die Aktion login angewendet wird. Der Zugriff wird blockiert, wenn der Wert unter 0,5 liegt.

     policy {
          path: login.php
          condition: recaptcha.score < 0.5
          action: block
        }

Bedingungsattribute für reCAPTCHA-Firewallrichtlinien

In der folgenden Tabelle sind reCAPTCHA-Tokenattribute aufgeführt, mit denen Sie Bedingungen in Ihren reCAPTCHA-Firewallrichtlinien definieren können.

Attributname Datentyp Beschreibung
recaptcha.token.valid boolean Gibt an, ob das empfangene Token gültig ist. Ein Token ist gültig, wenn es nicht fehlerhaft oder abgelaufen ist, auch wenn der Wert niedrig ist.
recaptcha.token.action String Der bei der Tokengenerierung angegebene Aktionsname. Wird nur für Aktionstokens ausgefüllt. Das ist der Parameter action, der beim Erstellen des Tokens an grecaptcha.enterprise.execute() übergeben wird. Weitere Informationen finden Sie unter Aktionsnamen.
recaptcha.score float Der Score eines reCAPTCHA-Tokens. Eine gültige Bewertung liegt zwischen 0,0 und 1,0. Ein Wert von 1,0 bedeutet, dass die Interaktion ein geringes Risiko darstellt und sehr wahrscheinlich legitim ist. 0,0 gibt hingegen an, dass die Interaktion ein hohes Risiko darstellt und betrügerisch sein kann. Weitere Informationen finden Sie unter Bewertungen auswerten.
recaptcha.assessment_type integer Die Art der durchgeführten Bewertung. assessment_type wird gemäß dem reCAPTCHA-Schlüssel für WAF festgelegt, der mit der Anfrage übergeben wird.

Verwenden Sie eine der folgenden Konstanten, um den Wert von recaptcha.assessment_type in Ihrem CEL-Ausdruck zu vergleichen:

  • AssessmentType.ACTION
  • AssessmentType.SESSION
  • AssessmentType.CHALLENGEPAGE
  • AssessmentType.EXPRESS
Wenn Sie beispielsweise eine Bewertung von Aktionstokens vergleichen möchten, verwenden Sie AssessmentType.ACTION.
http.ip String Die IP-Adresse der eingehenden Anfrage.
http.path String Der Pfad der Anfrage-URI.
http.domain String Die Domain des angeforderten URI.

reCAPTCHA-Firewallrichtlinienaktionen

In der folgenden Tabelle sind die verschiedenen Richtlinienaktionen aufgeführt, die Sie in Ihren reCAPTCHA-Firewallrichtlinien angeben können:

Richtlinienaktion Beschreibung Ergebnis der Aktion
allow Ermöglicht den Zugriff auf die angeforderte Seite. Die eingehende Nutzeranfrage wird ohne Unterbrechung an Ihr Backend weitergeleitet.
block Verweigert den Zugriff auf die angeforderte Seite. Dem Nutzer wird der HTTP-Fehler 403 (Verboten) zurückgegeben.
redirect Leitet die eingehende Nutzeranfrage an die reCAPTCHA-Abrufseite weiter. Auf der reCAPTCHA-Abfrageseite wird die Nutzeranfrage ausgewertet und ein Cookie basierend auf der Bewertung angehängt. Später wird die Nutzeranfrage noch einmal zur ursprünglichen Seite weitergeleitet.
substitute Es wird bei einer betrügerischen Nutzeranfrage eine andere Seite als die angeforderte Seite ausgeliefert. Der angeforderte Pfad wird durch einen anderen Pfad ersetzt, wenn die Anfrage an Ihr Backend gesendet wird. Der Nutzer sieht weiterhin die ursprüngliche URL.
set_header Hier wird ein benutzerdefinierter Header festgelegt und die eingehende Nutzeranfrage wird an das Backend weitergeleitet. Das Backend kann dann einen benutzerdefinierten Schutz auslösen. Der Nutzeranfrage wird ein Header hinzugefügt. Dein Backend verwendet diesen Header, um einen benutzerdefinierten Schutz oder eine benutzerdefinierte Analyse auszulösen.

Nächste Schritte