CAPTCHA verhindert Anmeldung oder Bestellung — sichere Wiederherstellung von Schlüsseln, Domain, Anbieter und Checkout‑Kompatibilität

Zweck

Dieser Leitfaden erklärt, wie man eine Blockade durch ein CAPTCHA (z. B. Google reCAPTCHA v2/v3 oder Äquivalent) diagnostiziert und behebt, die verhindert:

• die Anmeldung am Admin‑Bereich oder am Nutzerkonto;
• das Erstellen einer Bestellung oder die Zahlung (Checkout);
• die Registrierung oder das Zurücksetzen des Passworts.

Er behandelt die sichere Wiederherstellung von Schlüsseln, die Überprüfung der Domain und des Anbieters sowie Kompatibilitätsaspekte für WordPress/WooCommerce und PrestaShop (1.7 → 9).

Voraussetzungen

• Administratorzugang zum CMS (Administrationsoberfläche);
• Zugang zum CAPTCHA‑Anbieter (Google reCAPTCHA Account oder anderer Anbieter);
• Zugang zum Securantis‑Panel (SaaS), falls Sie die zentrale Konfiguration nutzen;
• Aktuelles Backup der Website (Dateien + Datenbank), bevor Sicherheitsänderungen vorgenommen werden, die die Authentifizierung betreffen.

Vor dem Eingreifen: wesentliche Vorsichtsmaßnahmen

• Senden Sie niemals Passwörter per E‑Mail oder Chat. Jede Zugriffsanforderung muss über den sicheren Kundenbereich für eine kostenpflichtige Intervention erfolgen.
• Entfernen Sie nicht automatisiert WAF‑Regeln und führen Sie keine Wiederherstellung ohne Validierung durch: Quarantäne und Entfernung bösartiger Dateien erfordern eine menschliche Entscheidung.
• Wenn das CAPTCHA serverseitig (SaaS/WAF) angewendet wird, beachten Sie, dass eine Fail‑Open/Fail‑Close‑Einstellung existieren kann; ändern Sie diese mit Vorsicht.

Gemeinsame Diagnoseschritte (für alle Plattformen)

1. Reproduzieren Sie den Fehler im Inkognito/Privaten Modus und ohne Browser‑Erweiterungen, um Cache und Extensions auszuschließen.
2. Identifizieren Sie den genauen Moment, in dem das CAPTCHA blockiert: Login‑Seite, Registrierung, Passwort vergessen, Checkout‑Schritt (Warenkorbbestätigung, Zahlung, Bank‑Weiterleitung).
3. Prüfen Sie die auf Client‑Seite sichtbaren Fehlermeldungen (JavaScript‑Konsole): Key‑Fehler, nicht autorisierte Domain, fehlende API‑Version oder geblockte Anfrage.
4. Prüfen Sie, ob die Blockade global ist (alle Nutzer) oder nur bestimmte IP‑Adressen/Regionen betrifft: bitten Sie einen Kollegen um Test oder verwenden Sie ein VPN.
5. Dokumentieren Sie die genaue Uhrzeit und die betroffene Seite — nützlich zur Korrelation mit WAF/Server‑Logs.

Sichere Wiederherstellung der Schlüssel und Domain‑Überprüfung

1. Melden Sie sich beim Konto des CAPTCHA‑Anbieters an (z. B. Google reCAPTCHA Console).
2. Prüfen Sie den Schlüsseltyp (v2 „checkbox“, v2 „invisible“ oder v3) und holen Sie den öffentlichen Schlüssel (site key) sowie den privaten Schlüssel (secret key).
3. Überprüfen Sie die Liste der autorisierten Domains für den Schlüssel:
   • Für HTTPS‑Sites stellen Sie sicher, dass die exakte Domain (mit oder ohne www, je nach Ihrer Site) eingetragen ist.
   • Für Multi‑Domains oder Staging‑Umgebungen fügen Sie explizit jede Domain hinzu oder verwenden Sie ein Wildcard, falls der Anbieter dies erlaubt.
4. Wurden Schlüssel kürzlich regeneriert, aktualisieren Sie die Konfiguration in Securantis und im CMS‑Modul/Plugin. Ein falscher Schlüssel verursacht Client‑Fehler im Browser oder Server‑Fehler.
5. Falls Sie einen Anbieter‑Fehler vermuten (Ausfall der CAPTCHA‑API), prüfen Sie die Statusseite des Anbieters oder testen Sie eine öffentliche Test‑Key, falls verfügbar.

Spezifika für WordPress & WooCommerce

Ziel: Formulare (Login, Registrierung, Passwort vergessen) und den WooCommerce‑Checkout schützen, ohne den Shop‑Frontend unnötig zu blockieren.

Schritte

1. Greifen Sie auf das CAPTCHA‑Konfigurationspanel in der Securantis‑Oberfläche oder im dedizierten WordPress‑Plugin zu (falls Sie eine lokale Integration aktiviert haben).
2. Prüfen Sie die unterstützte Version (v2 oder v3) und stellen Sie sicher, dass der Schlüssel dem ausgewählten Typ entspricht.
3. Überprüfen Sie in WooCommerce die unterstützten Positionen: Standard‑Checkout‑Felder, Kontoerstellung etc. Wenn Sie einen angepassten Checkout (Page Builder, Drittanbieter‑Payment‑Plugin) verwenden, testen Sie den Standard‑Checkout, um das Problem einzugrenzen.
4. Deaktivieren Sie temporär das CAPTCHA nur für den Checkout (sofern die Option besteht) und testen Sie, ob die Zahlung durchläuft. Lassen Sie den Checkout nicht länger als nötig ungeschützt.

Häufige Fehler und spezifisches Troubleshooting

• Fehler „nicht autorisierte Domain“: Fügen Sie die exakte Domain in der CAPTCHA‑Konsole hinzu (www/non‑www) und warten Sie einige Minuten auf die Propagierung.
• JavaScript‑Fehler (nicht vorhandener Schlüssel oder falsches Format): Bestätigen Sie, dass der public key korrekt in der Plugin‑Konfiguration eingetragen ist.
• Angepasster Checkout defekt: Einige Payment‑Plugins führen spezielle AJAX‑Submits durch — aktivieren Sie die WooCommerce‑Logs und vergleichen Sie die Network‑Anfragen, um zu prüfen, ob das CAPTCHA‑Token gesendet wird.
• reCAPTCHA v3‑Score zu niedrig: v3 vergibt einen Score; wenn Ihre Konfiguration einen hohen Schwellenwert verlangt, kann das legitime Nutzer abweisen. Senken Sie den Schwellenwert schrittweise oder testen Sie vorübergehend v2 für den Checkout.

Spezifika für PrestaShop (1.7 → 9)

Ziel: Sicherstellen, dass das CAPTCHA‑Modul für PrestaShop die Front‑Office‑Formulare (Kundenlogin, Kontoerstellung) und Checkout‑Schritte schützt, ohne die Finalisierung zu unterbrechen.

Schritte

1. Öffnen Sie das CAPTCHA‑Modul im Backoffice von PrestaShop und prüfen Sie die API‑Version (v2/v3) sowie die eingetragenen Schlüssel.
2. Wenn ein Drittanbieter‑Modul den Checkout beeinflusst (One Page Checkout, Zahlungsmodule), deaktivieren Sie temporär das CAPTCHA im Checkout, um zu prüfen, ob dieses das Problem verursacht.
3. Testen Sie den Ablauf mit der „Test‑Modus“‑Option, falls das Modul diese anbietet.

Häufige Fehler und Troubleshooting

• Modul nicht kompatibel mit Dritt‑Checkout: Einige CAPTCHA‑Module erkennen AJAX‑Submits oder angepasste Kontrollen von Zahlungsmodulen nicht. Kontaktieren Sie in diesem Fall den Herausgeber des Checkout‑Moduls, um die Kompatibilität zu prüfen.
• Token fehlt in der Server‑Anfrage: Aktivieren Sie die Logs des CAPTCHA‑Moduls (oder des Servers), um zu prüfen, ob das Token bei der Submission übertragen wird.

Vorsichtige Einstellungen und Empfehlungen

• Schalten Sie das CAPTCHA nicht dauerhaft „aus“ für den Checkout: Das setzt den Shop Bots und Betrugsversuchen aus.
• Um False‑Positives zu reduzieren, testen Sie: den v3‑Schwellenwert schrittweise senken, vorübergehend auf v2 „invisible“ wechseln oder das CAPTCHA nur auf bestimmte Formulare beschränken.
• Dokumentieren Sie jede Änderung (wer, was, warum) und stellen Sie die vorherige Konfiguration wieder her, falls die Änderung die Situation verschlechtert.

Fortgeschrittenes Troubleshooting

• Prüfen Sie die WAF/Securantis‑Logs, um die Blockade zu korrelieren: Überschneidungen zwischen WAF‑Regeln und CAPTCHA‑Prüfungen sind möglich.
• Untersuchen Sie die HTTP‑Header und CORS‑Header, wenn das Token von einer Dritt‑Domain geladen wird.
• Bei AJAX‑Problemen nutzen Sie die Netzwerk‑Tools des Browsers, um Vorhandensein und Format des Tokens in der POST‑Anfrage zu bestätigen.
• Meldet der CAPTCHA‑Anbieter, dass der Schlüssel gültig ist, Ihr Server das Token jedoch ablehnt, testen Sie mit einem Test‑Key oder erstellen Sie vorübergehend ein neues Schlüssel‑Paar zur Validierung.

Wann Sie den Securantis‑Support kontaktieren sollten

Kontaktieren Sie den Support, wenn:

• Sie Schlüssel und Domain geprüft haben und das CAPTCHA trotz korrekter Konfiguration weiterhin blockiert;
• die Blockade offenbar vom WAF/SaaS Securantis ausgeht (Korrelation in den Logs);
• Sie wiederkehrende Fehlereinträge in den Securantis‑Logs sehen und Unterstützung bei der Analyse wünschen;
• Sie ein Dritt‑Checkout‑Modul nutzen und Hilfe bei der Kompatibilitätsprüfung benötigen.

Informationen, die Sie dem Support bereitstellen sollten (nie Passwörter übermitteln)

1. Exakte URL der betroffenen Seite und Screenshots der clientseitigen Fehlermeldungen;
2. Uhrzeit(en) und Zeitzone der reproduzierbaren Versuche;
3. CAPTCHA‑Typ (reCAPTCHA v2 checkbox / v2 invisible / v3 oder anderes) und Bestätigung, dass site/secret keys überprüft wurden;
4. Angabe, ob der Checkout ein Dritt‑Modul nutzt (Name und Version);
5. Export relevanter Logs (WAF/Securantis) und Screenshots der Netzwerk‑Konsole, die Anfrage/Antwort zeigen (Token vorhanden oder fehlend, API‑Fehlercode).

Was Securantis kann und nicht kann

• Securantis kann bei der Analyse der Logs helfen, die Konfiguration auf SaaS‑Seite prüfen und Anpassungen an WAF‑Regeln oder CAPTCHA‑Einstellungen vorschlagen.
• Securantis wird keine Komponenten automatisch entfernen oder Ihre Schlüssel leichtfertig ändern; jede tiefgreifende Aktion (Wiederherstellung, Dateientfernung, Zugriffsänderung) erfordert Ihre ausdrückliche Zustimmung.

Erwartetes Ergebnis nach der Behebung

• Nutzer und Administratoren können sich wieder anmelden und Bestellungen normal abschließen;
• gültige CAPTCHA‑Anfragen werden von Ihrem Backend akzeptiert und die Tokens korrekt vom Frontend übermittelt;
• False‑Positives sind reduziert, ohne den Checkout einem Bot‑Risiko auszusetzen.

Fazit

Folgen Sie zuerst den Diagnoseschritten und der Prüfung von Schlüsseln/Domain, testen Sie mit einem Standard‑Checkout, um Konflikte mit Dritt‑Modulen einzugrenzen, und reichen Sie Logs sowie Screenshots beim Support ein, falls das Problem bestehen bleibt. Handeln Sie stets mit Vorsicht und erstellen Sie vor größeren Änderungen ein Backup.