Zum Hauptinhalt springen
Wer gestohlene Kreditkartennummern besitzt, weiß zunächst nicht, welche davon noch gültig sind. Um das herauszufinden, braucht er einen Shop, in dem er automatisiert eine Zahlung nach der anderen auslösen kann. Jeder Durchlauf kostet ihn nichts, Sie dagegen Rechenzeit, Gebühren beim Zahlungsdienstleister und im schlimmsten Fall Ihren Ruf als Händler. Genau dagegen richtet sich dieses Feature. Es erkennt wiederholte fehlgeschlagene Zahlungsversuche und sperrt die betroffene Zahlungsart vorübergehend, ohne den Bestellvorgang insgesamt abzubrechen. Der Käufer kann jederzeit mit einer anderen Zahlungsart weitermachen.

​
Wie der Schutz wirkt

Der Schutz arbeitet auf zwei Ebenen, die sich ergänzen. Die Sitzungsebene allein reicht nicht aus. Ein automatisierter Angriff holt sich einfach eine neue Sitzung und zählt von vorn. Erst die IP-Ebene setzt dem eine Grenze, weil sie über Sitzungsgrenzen hinweg zählt. Gesperrt wird immer nur die einzelne Zahlungsart, nie der Bestellvorgang. Wer versehentlich mehrfach eine falsche Kartennummer eingegeben hat, kann seine Bestellung weiterhin abschließen, nur eben beispielsweise per Rechnung oder Vorkasse. Das ist der Grund, warum die Hinweismeldungen im Template den Käufer ausdrücklich auf die anderen Zahlungsarten hinweisen sollten. Zusätzlich lässt sich ab einer bestimmten Anzahl von Fehlversuchen ein CAPTCHA erzwingen. Das ist die mildere Stufe: Der Käufer wird nicht ausgesperrt, muss aber nachweisen, dass er keine Maschine ist.

​
Schritt 1: Den Schutz in der global.config einrichten

Der Schutz wird im Abschnitt <PaymentBruteForceProtection> der global.config eingerichtet, nicht in der shop.config.
ProtectedPayments-List erwartet Zahlencodes, keine Namen. CreditCard schützt nichts, 1 schon. Die Codes entnehmen Sie der Referenz der Zahlungsarten. Eine Zahlungsart, die nicht in dieser Liste steht, ist von dem gesamten Feature nicht betroffen.
Referenz: Zahlungsarten und ihre Codes

​
Die Sperrstufen schreiben

Beide Sperrlisten haben dasselbe Format. Jede Stufe steht in einem eigenen Klammerpaar, davor die Zahl der Fehlversuche, dahinter die Sperrzeit in Sekunden.
Gelesen: Ab dem fünften Fehlversuch wird fünf Minuten gesperrt, ab dem zehnten eine halbe Stunde, ab dem zwanzigsten dauerhaft. Es gilt immer die höchste Stufe, deren Schwelle erreicht ist. Die Reihenfolge in der Konfiguration spielt deshalb keine Rolle, Sie dürfen die Stufen auch unsortiert notieren. Lesbar bleibt es aufsteigend.
Verwenden Sie niemals 0 als Schwelle. Der Shop liest die Liste nur bis zur ersten Stufe mit der Schwelle 0, alle folgenden Stufen fallen ersatzlos weg. Aus (0:60)(10:600) wird damit keine Sperre.permanent funktioniert nur in BlockTimesPerSession-List. In BlockTimesPerIP-List führt eine als permanent markierte Stufe dazu, dass überhaupt keine IP-Sperre gesetzt wird. Der Shop sperrt IP-Adressen bewusst nie dauerhaft, weil hinter einer IP-Adresse ganze Firmen oder Mobilfunknetze stehen können. Notieren Sie für die IP-Liste deshalb ausschließlich Sekundenwerte.
Die Sperrzeit ist auf 172800 Sekunden begrenzt, also auf 48 Stunden. Ein höherer Wert wird stillschweigend auf diese Grenze gesetzt. Dasselbe gilt für BlockTimesPerIP-ObservationWindowInMinutes, das auf 2880 Minuten begrenzt ist.

​
Das Beobachtungsfenster

BlockTimesPerIP-ObservationWindowInMinutes legt fest, wie weit der Shop beim Zählen der Fehlversuche einer IP-Adresse zurückschaut. Bei 60 zählen nur die Fehlversuche der letzten Stunde. Ein kurzes Fenster verzeiht schnell und trifft geteilte Anschlüsse seltener. Ein langes Fenster erkennt auch langsame, über Stunden verteilte Angriffe. Fangen Sie eher mit einer Stunde an und verlängern Sie erst, wenn Sie einen verteilten Angriff tatsächlich beobachten.

​
Das CAPTCHA

ForceCaptchaAfterXAttempts legt fest, ab wie vielen Fehlversuchen der Käufer ein CAPTCHA lösen muss. UseCaptcha bestimmt den Dienst.
Nur diese drei Werte werden erkannt. Jede andere Schreibweise, auch ein Tippfehler wie friendly-captcha, schaltet das CAPTCHA stillschweigend ab. Es gibt dafür keine Fehlermeldung.
CaptchaErrorHandling = fail-open bestimmt, was passiert, wenn der CAPTCHA-Dienst selbst nicht erreichbar ist. Mit fail-open lässt der Shop den Käufer in diesem Fall durch. Das hält Ihren Shop bestellbar, wenn ein externer Dienst ausfällt, öffnet aber genau in diesem Moment die Tür. Ohne diesen Wert wird ein nicht prüfbares CAPTCHA als nicht bestanden gewertet.

​
Schritt 2: Die Hinweismeldungen ins Template einbauen

Ergänzen Sie das Template der Bestellübersichtsseite, üblicherweise ws_place_order.htm, um die folgenden Meldungen. Sie gehören außerhalb des Formulars der Bestellübersicht.
Die Verschachtelung von PBP-Blocked_untilTimestamp in {!PBP-Blocked_infinite} ist nicht Geschmackssache. Bei einer dauerhaften Sperre trägt der Shop intern trotzdem einen Endzeitpunkt ein, und der liegt rechnerisch viele Jahrzehnte in der Zukunft. Ohne die Verschachtelung würde der Käufer eine absurde Jahreszahl lesen.
Alle PBP-Tags beziehen sich immer auf die gerade gewählte Zahlungsart. ~WS-Payment~ in den Meldungen benennt deshalb genau die Zahlungsart, um die es geht. Ein zweiter Block für eine andere Zahlungsart ist nicht nötig.

​
Schritt 3: Den Schutz testen

Sie können eine fehlgeschlagene Zahlung simulieren, ohne eine echte Zahlung auszulösen. Hängen Sie dazu an einen beliebigen Shop-Aufruf die beiden URL-Parameter test=on und order-failed=on an.
Die Bestellung schlägt beim Absenden fehl, und der Fehlversuchszähler des Schutzes wird hochgezählt. So prüfen Sie den CAPTCHA-Zwang und Ihre Hinweismeldungen, ohne auf echte Fehlversuche warten zu müssen. Der Produktivbetrieb Ihres Shops wird dadurch nicht beeinflusst. Die Parameter wirken nur in dem Aufruf, an den Sie sie anhängen.
Testen Sie die IP-Sperre bewusst und nicht nebenbei. Sie gilt für Ihre IP-Adresse und damit möglicherweise für Ihr ganzes Büro. Wählen Sie für den Test eine Zahlungsart, die Sie nicht produktiv brauchen, oder eine kurze Sperrzeit.

​
Was der Schutz nicht leistet

Der Schutz zählt Fehlversuche, er bewertet sie nicht. Er unterscheidet nicht zwischen einem Angreifer und einem Käufer, der seine Karte dreimal falsch abgetippt hat. Setzen Sie die Schwellen deshalb nicht zu niedrig an. Drei bis fünf Fehlversuche bis zum CAPTCHA und deutlich mehr bis zur ersten Sperre sind ein brauchbarer Anfang. Ein verteilter Angriff über viele verschiedene IP-Adressen läuft an der IP-Ebene vorbei. Der Schutz erschwert automatisierte Angriffe erheblich, ersetzt aber nicht die Betrugserkennung Ihres Zahlungsdienstleisters.

​
Verwandte Themen