Rabattcodes in der Black Week: Missbrauch früh erkennen

Ein Gutscheincode funktioniert wie ein Passwort ohne Benutzernamen. Er schaltet einen Vorteil frei, der sich in Geld umrechnen lässt, und der Shop prüft bei jeder Eingabe, ob er gültig ist. Für Login-Geheimnisse begrenzt NIST aufeinanderfolgende Fehlversuche je Konto auf höchstens 100 und sperrt das Zugangsmerkmal danach (NIST SP 800-63B). Am Gutscheinfeld fehlt dieses Konto: Es gibt nichts, das nach zu vielen Fehlversuchen gesperrt wird, und keinen Besitzer, der eine Warnmail bekommt. Wer dort rät, stört zunächst niemanden, und die Antwort des Shops verrät bei jedem Versuch, ob er richtig lag.

Das OWASP-Projekt ordnet diesem Muster die Schwächen CWE-799 und CWE-837 zu (OWASP Automated Threats). Die erste beschreibt eine Anwendung, die Zahl oder Häufigkeit der Interaktionen mit einem Akteur nicht ausreichend begrenzt (MITRE CWE). Die zweite beschreibt eine Anwendung, die eine nur einmal zulässige Aktion nicht oder unzureichend durchsetzt (MITRE CWE). Beides trifft auf Gutscheine zu: Gegen das Raten hilft eine Frequenzbremse, gegen die Mehrfacheinlösung eine harte Einmalprüfung.

Der Angriffskatalog CAPEC beschreibt den Kern der Rechnung im Eintrag CAPEC-112: Entscheidend ist, wie schnell ein Angreifer den Raum möglicher Geheimnisse absuchen kann (MITRE CAPEC). Der Verteidiger muss dafür sorgen, dass Zeit und Aufwand dafür den Wert des Erbeuteten übersteigen (MITRE CAPEC). Für Rabattcodes heißt das: Der Zeichenraum muss groß genug sein, die Versuche müssen gebremst werden, und der Shop muss es bemerken, wenn trotzdem jemand sucht. In der Black Week wiegen diese drei Punkte schwerer als sonst. Viele Aktionen laufen parallel, Codes werden über Newsletter, Partner und soziale Kanäle verteilt, und ein auffälliger Verlauf geht im allgemeinen Lastanstieg leicht unter.

Wie viel Schutz ein Code aus sich selbst heraus bietet, lässt sich vor der Aktion ausrechnen. Shopware erzeugt individuelle Aktionscodes wahlweise mit fester Länge oder nach einem eigenen Muster, in dem %s für einen zufälligen Buchstaben von A bis Z und %d für eine zufällige Ziffer von 0 bis 9 steht (Shopware-Dokumentation). Das Beispielmuster der Dokumentation, SW-%s%d%s%d%s-TEST, enthält fünf Zufallsstellen: drei Buchstaben und zwei Ziffern. Das ergibt 1.757.600 mögliche Codes (eigene Rechnung nach Shopware-Dokumentation).

Entscheidend ist eine zweite Größe: wie viele davon gültig sind. Ein Angreifer sucht nicht einen bestimmten Code, sondern irgendeinen der ausgegebenen. Bei 10.000 Codes einer Newsletter-Aktion ist im Mittel jeder 176. zufällige Versuch ein Treffer (eigene Rechnung nach Shopware-Dokumentation). Die Tabelle zeigt, wie sich das mit der Länge verschiebt – als eigene Rechnung mit 10.000 gültigen Codes und angenommenen 1.000 Versuchen je Sekunde ohne Bremse.

Zwei Folgerungen ergeben sich daraus. Erstens darf aus einem kurzen Muster keine Serie mit tausenden Codes werden, ohne dass Zufallsstellen hinzukommen: Jeder zusätzlich ausgegebene Code macht das Raten leichter. Zweitens ersetzen auch zwölf Zeichen die Bremse nicht. Ein Code aus 12 Zeichen eines 32-Zeichen-Satzes trägt 60 Bit Zufall. Für Einmalcodes aus OTP-Generatoren, etwa Authentifizierungs-Apps, verlangt NIST unterhalb von 64 Bit ein Rate-Limit für Fehlversuche (NIST SP 800-63B). Ein Gutscheincode ist kein Login, die Logik dahinter passt trotzdem – zumal die Zahl der Versuche je Sekunde der Angreifer bestimmt, nicht der Shop.

Eine Bremse ohne Messung bleibt stumm: Sie greift, aber niemand erfährt davon. Fehlversuche am Gutscheinfeld gehören darum als eigene Kennzahl ins Monitoring, aufgeteilt nach Minute, Verkaufskanal und Herkunft. Den Normalwert liefert der Shop selbst. In ruhigen Wochen bewegt sich die Zahl ungültiger Codeeingaben in einem schmalen Band, an Aktionstagen steigt sie mit den Besuchern. Der Alarm vergleicht deshalb nicht mit einer festen Zahl, sondern mit dem Verhältnis von Fehlversuchen zu Warenkörben.

Die OWASP API Security Top 10 nennen als Gegenmittel gegen automatisierten Zugriff auf sensible Geschäftsabläufe die Suche nach nicht menschlichen Mustern, etwa wenn zwischen „in den Warenkorb“ und „Kauf abschließen“ weniger als eine Sekunde liegt (OWASP API Security Top 10). Am Gutscheinfeld sehen solche Muster so aus: Versuche im Abstand von Millisekunden, Codes in alphabetischer oder numerischer Folge, viele Eingaben ohne einen einzigen Artikelwechsel und Anfragen ohne vorherigen Seitenaufruf. Ein erster Blick gelingt schon mit dem Zugriffsprotokoll des Webservers. Die Storefront nimmt Codes über die Route POST /checkout/promotion/add entgegen (Shopware-Quelltext):

Das Zugriffsprotokoll zeigt Versuche, aber nicht, ob ein Code gültig war. Für einen ersten Alarm reicht das: Wer in einer Minute zwanzig Codes ausprobiert, kauft nicht gewöhnlich ein. Den Ausgang jeder Eingabe kennt nur die Anwendung. Dort gehört ein eigener Protokolleintrag hin, der Zeitpunkt, Warenkorb, Konto und Ergebnis festhält, aber nicht den vollständigen Code. Gekürzt auf die ersten Zeichen bleibt er für die Mustersuche brauchbar und gibt im Protokoll keinen gültigen Code preis.

Wie Schwellen, Eskalation und Alarmmüdigkeit zusammenspielen, beschreibt der Beitrag zu Log-Monitoring und Alerting. Für das Gutscheinfeld genügt am Anfang eine Stufe für den Tagesbericht und eine für die sofortige Benachrichtigung.

Nicht jeder Missbrauch braucht einen Bot. Ein Code, der für den Newsletter gedacht war, kann kurz nach dem Versand auf Gutscheinportalen und in Schnäppchenforen stehen. Ab dann lösen ihn Besucher ein, für die er nicht gedacht war, und die Aktion kostet mehr als geplant. Technisch ist das kein Angriff, im Monitoring sieht es trotzdem nach einem aus: Die Einlösungen eines Codes steigen sprunghaft, neue Besucher kommen über fremde Verweise, und der Anteil der Bestandskunden unter den Einlösenden fällt.

Das wirksamste Gegenmittel ist die Wahl der Codeart. Shopware unterscheidet feste Aktionscodes, die für alle Kunden gleich sind, von individuellen Codes, die nur einmal eingelöst werden können und bei erneuter Eingabe abgelehnt werden (Shopware-Dokumentation). Feste Codes lassen sich über die Felder für die maximale Nutzung insgesamt und je Kunde begrenzen (Shopware-Dokumentation). Bei individuellen Codes gilt außerdem: Werden die Codes einer Aktion nachträglich angepasst und neu erzeugt, verlieren die bisherigen ihre Gültigkeit (Shopware-Dokumentation). Im Normalbetrieb ist das eine Falle, im Missbrauchsfall ein Werkzeug – vorausgesetzt, die berechtigten Empfänger erhalten danach neue Codes.

Für die Erkennung lohnt der Blick auf die Herkunft der Einlösungen. Tragen eingelöste Codes eines Kanals plötzlich Verweise von fremden Seiten, oder lösen Konten ohne Newsletter-Anmeldung einen Newsletter-Code ein, ist der Code durchgesickert. Die Reaktion richtet sich nach dem Schaden: eine Gesamtgrenze setzen, den Code früher beenden oder ihn für neue Warenkörbe sperren und den berechtigten Empfängern einen Ersatz schicken.

Manche Aktion endet auf dem Papier und läuft im Shop weiter. Shopware begrenzt eine Aktion über ein Gültigkeitsdatum von und bis und lässt sie über einen Schalter deaktivieren (Shopware-Dokumentation). Beides muss zum veröffentlichten Aktionsende passen, einschließlich der Uhrzeit. Steht in der Werbung „bis Montag, 23:59 Uhr“, muss das Gültigkeitsende genau diese Uhrzeit in der Zeitzone des Shops treffen. Nach dem Ende beginnt die Auswertung. Eine kurze Liste schließt die Aktion sauber:

Für Shopbetreiber ist Codemissbrauch selten das tägliche Thema. Ohne eigene Kennzahl fällt er darum leicht erst in der Monatsauswertung auf, wenn die Marge der Aktion schon fehlt. In einem Wartungsvertrag gehört er zum laufenden Betrieb: Unser Monitoring wertet Webserver- und Anwendungsprotokolle auf kritische und verdächtige Zugriffsmuster aus, die Alarmschwellen werden individuell für den Shop eingestellt, und für Black Friday und das Weihnachtsgeschäft verkürzen wir Prüfintervalle, setzen Schwellen enger und erweitern die Bereitschaft.

Die Abwehr auf Netzebene ist Teil der Sicherheitsupdates: Wir konfigurieren und pflegen WAF-Regeln, prüfen Updates vorab auf Staging einschließlich Checkout und ziehen Schutzmaßnahmen nach, wenn ein neues Angriffsmuster auftaucht. Eine eigene Bremse in der Anwendung erweitert den Funktionsumfang und wird deshalb als eigenes Projekt angeboten; die Shopware-Wartung prüft sie danach bei jedem Update mit. Reaktionszeiten und Bereitschaft in der Aktionswoche regelt der SLA-Wartungsvertrag.

Kommt ein Angriff trotzdem durch, beginnt der Ablauf aus dem Notfall-Support: Code sperren, Bremse verschärfen, Einlösungen sichten und betroffene Bestellungen vor dem Versand prüfen. Einen Überblick über alle Bausteine der Betreuung gibt die Seite Leistungen.