Die meisten Warnungen vor gefälschten Bezahlseiten laufen auf denselben Rat hinaus: Achten Sie auf die Adresse im Browser. Der Fall, den das Bundesamt für Cybersicherheit Anfang September beschreibt, macht diesen Rat wertlos. Denn die Adresse stimmte.
Betroffen war ein Schweizer Essenslieferdienst. Angreifer hatten es geschafft, eigenes JavaScript in die echte Website einzuschleusen. Was danach passierte, ist bemerkenswert gut durchdacht.
Wie der Angriff ablief
Beim Bezahlen war die gewohnte Option Twint verschwunden. An ihrer Stelle stand «Credit/Debit Card». Wer darauf klickte, bekam ein Formular für die Kartendaten — auf Englisch, obwohl die ganze Seite deutsch ist. Die eingegebenen Daten gingen an eine Adresse, die den Angreifern gehörte.
Und dann kommt der Teil, der den Unterschied macht: Es erschien eine Fehlermeldung, die zur Zahlung per Twint zurückführte. Die Bestellung wurde ganz normal abgeschlossen. Das Essen kam.
Damit gab es für die Kundschaft keinen Anlass zur Nachfrage — bezahlt wurde ja am Ende wie immer, die Lieferung kam an, alles schien in Ordnung. Und der Betreiber hörte aus demselben Grund nichts: Keine Beschwerden, keine fehlgeschlagenen Bestellungen, keine Auffälligkeit in den Zahlen. Der Diebstahl fiel erst später auf, über die gestohlenen Karten.
Warum das jeden Betrieb mit Bezahlfunktion angeht
Dieser Angriff heisst Web-Skimming, und er ist deshalb heimtückisch, weil er die Website nicht kaputt macht. Eine gehackte Seite, die plötzlich Werbung für zweifelhafte Medikamente zeigt, merkt man. Ein Skimmer will genau das nicht — er will, dass alles weiterläuft.
Hereingekommen ist das Skript auf einem der üblichen Wege: über eine veraltete Erweiterung, ein gekapertes Konto oder eine eingebundene Fremdbibliothek. Wie schnell Letzteres geht, haben wir beim Lieferkettenangriff über ein CDN beschrieben — dort wurde der Schadcode über den Auslieferungsweg des Herstellers verteilt, ohne dass eine einzige Website selbst angegriffen werden musste.
Der Schutz, der in den Meldungen untergeht
Das BACS nennt fünf Empfehlungen. Vier davon sind bekannt: Komponenten aktuell halten, eingebundene JavaScript-Bibliotheken prüfen, den Checkout regelmässig selbst durchklicken, Zwei-Faktor-Anmeldung für Administratoren.
Die fünfte wird selten erklärt, und sie ist bei diesem Angriff die wirksamste: eine restriktive Content Security Policy.
Vereinfacht gesagt ist das eine Liste, die der Server mitschickt und die dem Browser sagt, was auf dieser Seite erlaubt ist — welche Skripte laufen dürfen, und vor allem: wohin Daten geschickt werden dürfen. Genau daran scheitert ein Skimmer. Er kann die Karte auslesen, aber er bringt sie nicht weg.
Zwei Angaben in dieser Liste tun die Arbeit. Die eine begrenzt, zu welchen Adressen die Seite überhaupt Verbindungen aufbauen darf. Die andere legt fest, dass ein Formular nur an die eigene Domain abgeschickt werden kann. Beides steht auf cyberdine.ch produktiv im Einsatz.
Was eine solche Liste nicht leistet
Hier ist Ehrlichkeit wichtiger als ein gutes Verkaufsargument. Eine Content Security Policy verhindert nicht, dass fremder Code ausgeführt wird. Auch unsere eigene erlaubt aus praktischen Gründen Skripte, die direkt in der Seite stehen — dieselbe Einstellung findet sich auf den allermeisten Websites, weil sonst gängige Bausteine nicht mehr funktionieren.
Der Schutz liegt woanders: nicht darin, die Ausführung zu unterbinden, sondern den Abtransport. Ein Skimmer, der die Daten nicht wegschicken kann, ist wirkungslos, auch wenn sein Code läuft.
Das ist kein vollständiger Schutz, und wer ihn so verkauft, übertreibt. Es ist eine zusätzliche Schranke, die diesen konkreten Angriff ins Leere laufen lässt — und sie kostet nichts ausser der Sorgfalt beim Einrichten.
Was wir empfehlen
Klicken Sie Ihren eigenen Bestellvorgang durch. Nicht überfliegen, sondern bis zur Zahlungsauswahl gehen. Fehlt eine gewohnte Option? Ist plötzlich eine neue da? Wechselt die Sprache? Genau diese drei Dinge waren im beschriebenen Fall die Merkmale.
Fragen Sie, ob Ihre Website eine Content Security Policy mitschickt. Das ist eine Frage, die Ihr Anbieter oder Ihre Agentur in einem Satz beantworten kann. Lautet die Antwort nein, ist das kein Notfall — aber ein lohnendes Vorhaben für den nächsten Wartungstermin.
Und behalten Sie im Blick, was Ihre Seite von fremden Servern nachlädt. Jede eingebundene Bibliothek ist ein Weg hinein, den Sie nicht selbst kontrollieren.
Wenn Sie unsicher sind, ob auf Ihrer Seite etwas läuft, das dort nicht hingehört: Wir sehen uns das an — und wenn es tatsächlich etwas gibt, gehört das zur Hack- und Malware-Bereinigung. Was bei einem Verdacht zuerst zu tun ist, steht in unserer Ersten Hilfe.