Grenzen des Schutzes kennen

Der Seitenschutz von Bot Shield deckt die Storefront-Seiten ab, die dein Shop selbst rendert. Eine Lücke, die niemand benennt, wird so eingestellt, als wäre sie abgedeckt. Deshalb steht hier, welche Arten von Datenverkehr den Schutz strukturell nie erreichen — und was du jeweils tun kannst.

Dateien, die der Webserver ausliefert

Bilder, Skripte und andere statische Dateien beantwortet der Webserver, bevor PHP läuft; der Schutz sieht diese Anfragen nie. Fällt eine solche Anfrage doch bis zu PHP durch, zählt sie gegen das Tempo-Limit für sonstige Anfragen, die verhaltensbasierten Signaturen greifen dort aber nicht.

Das kannst du tun: Schütze diese Dateien dort, wo sie ausgeliefert werden — im Webserver oder in deinem CDN.

Seiten aus dem HTTP-Cache

Eine Seite, die aus dem HTTP-Cache beantwortet wird, ist ein Teilfall. Eine Adresse auf deiner Sperrliste wird dort im Modus Durchsetzen weiterhin abgewiesen, und auch die Sicherheitsprüfung für unbekannte Besucher greift bei Cache-Treffern. Die Erkennung läuft bei einem Cache-Treffer aber nicht: Die Seitenaufrufe einer nicht gelisteten Adresse bauen keine Vorgeschichte auf und können nie zu einer automatischen Sperre führen.

Wird der Seiten-Cache von einem vorgeschalteten Server oder CDN ausgeliefert, sieht der Shop diese Seitenaufrufe gar nicht. Dann bleibt auch die Erkennung von Kaufmengen-Abfragen ohne Seitenaufruf wirkungslos. php bin/console coe:bot-shield:config:doctor sagt dir für deinen Shop, welcher Fall vorliegt.

Das kannst du tun: Betrachte den ersten Aufruf einer Seite ohne Cache als den, den der Schutz sieht, und verlass dich nicht darauf, dass ein warmer Cache dich schützt.

Datenverkehr unter dem Limit

Bleibt die Menge einer einzelnen Adresse unter dem eingestellten Limit, ist das keine Überschreitung — die Tempo-Erkennung vergibt dafür keinen Verstoß. Im Free-Tarif ist die Tempo-Erkennung die einzige Erkennung.

Das kannst du tun: Nutze im Basic-Tarif die verhaltensbasierten Signaturen, oder trage einen Netzbereich, den du als feindlich kennst, manuell in die Sperrliste ein.

Verteilte, unauffällige Flotten

Viele Adressen, die sich jeweils unauffällig verhalten, können zusammen eine koordinierte Last ergeben. Löst der Datenverkehr einer Flotte die Verhaltens-Signaturen aus, sperrt der Schutz den Bereich in den bezahlten Tarifen im Modus Durchsetzen automatisch. Eine Flotte ohne Signatur-Treffer ist eine „Clean-Flotte“: Sie wird in den bezahlten Tarifen erkannt, aber nur als Vorschlag — du gibst sie frei, bevor etwas gesperrt wird. Im Free-Tarif gibt es diese Erkennung nicht. Eine Flotte unterhalb der Mindestanzahl Hosts bleibt in jedem Tarif unsichtbar für die Flotten-Erkennung.

Das kannst du tun: Prüfe die Vorschläge in der Übersicht und schütze einen Bereich, den du kennst und dem du vertraust, mit der Freigabeliste.

Anfragen über die Schnittstelle des Shops

Ein Headless-Frontend, eine App oder eine Integration spricht mit dem Shop über die API statt über gerenderte Seiten. Das Seiten-Gate läuft dort nicht: Admin, Admin-API und Store-API liegen außerhalb des Schutzbereichs, API-Aufrufe für Listing und Suche werden nicht gezählt, und Sperr- und Freigabeliste erreichen sie nicht. Ausnahmen sind die Registrierung und die Bestellung über die API — diese beiden Wege schützt der Registrierungsschutz eigenständig.

Das kannst du tun: Schütze die API vor dem Shop — im Webserver, in deinem CDN oder in einem API-Gateway, denn die Listen des Plugins enden an der Storefront.

Formulareingaben bei einer Sicherheitsprüfung

Wird bei einer Registrierung eine Sicherheitsprüfung gestellt, löst der Besucher sie und landet wieder im Registrierungsformular. Seine Eingaben stehen danach einmal wieder im Formular, nur für denselben Browser; der Server hält sie nur so lange, wie die Prüfung gültig bleibt. Das Passwort wird bewusst nicht gespeichert und muss erneut eingegeben werden. Wird eine Sicherheitsprüfung beim Absenden der Kasse gestellt, bleiben die Eingaben nicht erhalten und müssen erneut gemacht werden. Das zugehörige Cookie steht in den Cookie-Einstellungen unter den notwendigen Cookies und braucht keine Einwilligung.

Das kannst du tun: Für die Registrierung ist nichts nötig. Sagst du Besuchern, die nach einer Prüfung ein leeres Formular melden, dass sie ihre Eingaben in der Kasse erneut machen müssen, ersparst du dir Rückfragen. Nimm die Cookies des Plugins in deine Datenschutzerklärung auf.

Absendungen, die keine Prüfung beantworten können

Bei Registrierung und Kasse wird eine Sicherheitsprüfung nur gestellt, wo sie sich auch beantworten lässt. Eine im Hintergrund abgeschickte Absendung — durch ein Skript auf der Seite statt durch einen Besucher, der das Formular absendet — kann keine Prüfung lösen. Sie wird deshalb protokolliert und durchgelassen, statt eine unlösbare Prüfung zu bekommen. Eine Adresse, die solche Einträge dauernd erzeugt, wird in den bezahlten Tarifen im Modus Durchsetzen automatisch gesperrt, sobald die Reaktion der Prüfung auf Markieren statt auf Rechenaufgabe steht. Wo die Registrierungsgrenze überschritten ist, antwortet der Shop weiterhin mit einer Begrenzung.

Das kannst du tun: Beobachte die markierten Einträge in der Übersicht, nutze das Registrierungslimit und die Sperrliste für Datenverkehr, den du stoppen willst, und die Freigabeliste für eine Adresse, die die automatische Sperre auslassen soll.