Scarnox · Blog

So funktioniert reCAPTCHA v2 und wie man es löst (demnächst verfügbar)

reCAPTCHA v2 ist Googles klassisches Captcha. Es zeigt ein Kästchen mit der Beschriftung "Ich bin kein Roboter" und, wenn es sich über den Besucher nicht sicher ist, eine Bildaufgabe. Ein Solver dafür muss ein gültiges Antwort-Token erzeugen, das die Seite bei Google prüfen lassen kann. Die Unterstützung von reCAPTCHA v2 bei Scarnox kommt demnächst. Dieser Leitfaden erklärt, wie das Widget funktioniert, welche allgemeinen Ansätze heute verbreitet sind und was du von einem token-basierten Solver erwarten kannst.

Scarnox löst reCAPTCHA v2 noch nicht live. Der einzige heute live verfügbare Task-Typ ist PopularCaptcha, proxyless. Wenn dein Projekt jetzt reCAPTCHA v2 braucht, sind die folgenden Ansätze die realistischen Optionen.

So funktioniert das Widget

Die Seite bettet ein Container-Element mit einem Attribut data-sitekey ein. Dieser Sitekey identifiziert die Seite gegenüber Google. Wenn das Widget lädt, führt es Prüfungen im Browser durch, schaut auf das Verhalten, die Cookies und den Verlauf des Besuchers und schickt eine Risikobewertung an Google.

Ist die Bewertung unauffällig, setzt sich das Kästchen von selbst, und das Widget schreibt ein Token in ein verstecktes Feld namens g-recaptcha-response. Ist das Risiko höher, sieht der Besucher eine Bildaufgabe, etwa das Auswählen von Kacheln mit einem bestimmten Objekt. Das Bestehen der Aufgabe schreibt ebenfalls das Token.

Das Backend der Seite schickt dieses Token dann an den Prüfendpunkt von Google, zusammen mit dem geheimen Schlüssel der Seite. Google antwortet mit Erfolg oder Fehler. Weil die Prüfung auf dem Server stattfindet, ist ein Formular, das ein Token akzeptiert, ohne es bei Google zu prüfen, durch reCAPTCHA gar nicht geschützt.

Warum es markiert wird

Das Kästchen ist eine Risikoentscheidung, kein Rätsel. Typische Auslöser sind:

Diese Auslöser zu verstehen ist wichtiger als das Widget selbst. Wenn dein Datenverkehr das Kästchen nicht auslöst, siehst du nie die Bildaufgabe.

Allgemeine Ansätze, die heute funktionieren

Diese Ansätze sind weit verbreitet, und sie sind ehrlich. Sie verringern, wie oft eine Prüfung bei legitimer Arbeit erscheint.

  1. Echte Sitzungen führen. Verwende Cookies und ein konsistentes Browser-Profil über eine Sitzung hinweg, statt bei jeder Seite neu zu beginnen.
  2. Anfragen takten. Ein gleichmäßiges, langsames Tempo wirkt weit mehr wie eine Person als ein Schwall.
  3. Für das Widget einen echten Browser nutzen. Ein vollständiger Browser mit normalen Einstellungen wird seltener markiert als ein abgespecktes Headless-Setup. Der Leitfaden zur Headless-Browser-Erkennung listet die häufigen Signale auf.
  4. Eine Ausnahme oder einen Testschlüssel anfragen. Wenn dir die Seite gehört, verwende Googles veröffentlichte Testschlüssel in der Staging-Umgebung. Wenn nicht, bitte den Betreiber um eine Allowlist.
  5. Eine Person im Ablauf einbinden. Bei Aufgaben mit geringem Volumen kann ein Mensch das Kästchen anklicken und das Token weitergeben. Das ist langsam, aber zuverlässig.

Diese Ansätze garantieren nicht, dass nie eine Aufgabe erscheint. Sie verringern die Häufigkeit, und das hält einen legitimen Job stabil.

Was ein token-basierter Solver tut

Ein token-basierter Solver für reCAPTCHA v2 macht dasselbe wie PopularCaptcha heute. Er nimmt Sitekey und Seiten-URL, erzeugt ein gültiges Token g-recaptcha-response und gibt es an deinen Code zurück. Dein Code trägt das Token dann ins Formular ein und sendet es ab, bevor das Token abläuft.

Scarnox wird den Task-Typ und alle zusätzlichen Felder in der API-Referenz dokumentieren, sobald die Unterstützung für reCAPTCHA v2 veröffentlicht ist. Bis dahin baue nicht auf einer vermuteten Schnittstelle auf. Die Anfrage wird dem PopularCaptcha-Beispiel ähnlich sein, aber prüfe die Doku für die genauen Werte.

Checkliste für einen reCAPTCHA-v2-Job

Wenn du einen Job planst, der ein Formular mit reCAPTCHA v2 berührt, prüfe diese Punkte:

Häufige Fehler

Der häufigste Fehler bei einer reCAPTCHA-v2-Integration ist ein Token, das die Seite ablehnt, obwohl es richtig aussieht. Drei Ursachen erklären die meisten davon. Erstens eine Abweichung zwischen Sitekey und Seiten-URL: Das Token ist an die Seite gebunden, auf der das Widget angezeigt wurde, daher schlägt ein Sitekey von einer Seite fehl, der auf einer anderen abgeschickt wird. Zweitens ein veraltetes Token. Tokens sind kurzlebig, daher sendet ein Skript, das zuerst löst und dann eine lange Reihe anderer Schritte ausführt, einen abgelaufenen Wert ab. Drittens fehlt eine serverseitige Prüfung auf deiner Seite. Wenn deine eigenen Tests nur bestätigen, dass ein Token existiert, bemerkst du nicht, dass der Prüfschritt fehlschlägt.

Eine zweite Gruppe von Fehlern kommt aus dem Ablauf rund um das Widget. Ein Login in einer Sitzung und das Absenden des Formulars aus einer anderen ist ein häufiger Fall, weil die Prüfung von der Sitzung abhängen kann, die das Widget geladen hat. Ein abgelehntes Formular viele Male hintereinander erneut abzusenden lässt die Sitzung ebenfalls verdächtig wirken, was aus einer einzelnen Aufgabe eine ganze Serie machen kann. Wenn etwas fehlschlägt, pausiere, prüfe den Zustand der Seite und versuche es einmal mit frischen Werten erneut.

Verantwortungsvoll scrapen

Wenn das Formular Teil eines Scraping-Jobs ist, prüfe robots.txt und die Nutzungsbedingungen der Seite, bevor du anfängst. Halte die Rate niedrig und erhebe keine personenbezogenen Daten, die du nicht brauchst. Der Leitfaden zur Legalität von Web-Scraping behandelt die wichtigsten Gesichtspunkte.

Nächste Schritte