Drittanbieter-Skripte auf der Zahlungsseite: Was PCI DSS verlangt

Jedes Skript, das auf der Zahlungsseite läuft (Chat, Webanalyse, Tag-Manager, Bewertungen, Marketing-Pixel), kann grundsätzlich sehen, was der Kunde eintippt. Deshalb verlangt PCI DSS in Anforderung 6.4.3 ein Inventar aller dieser Skripte mit Begründung, ein Verfahren zur Freigabe jedes einzelnen und eines, das sicherstellt, dass sie nicht verändert wurden; und in Anforderung 11.6.1 einen Mechanismus, der Änderungen an der Seite, wie sie beim Kunden ankommt, erkennt und das Team alarmiert, mindestens einmal pro Woche. Beide Regeln sind seit dem 31. März 2025 verpflichtend.

Warum Drittanbieter-Skripte das schwache Glied sind

Ein Drittanbieter-Skript liegt nicht auf Ihrem Server: Der Browser des Kunden lädt es bei jedem Besuch vom Server des Anbieters. Wird dieser Anbieter gehackt oder ändert er die Datei, ändert sich Ihre Seite mit, ohne dass Ihr Team etwas veröffentlicht hat. Der Leitfaden des PCI Security Standards Council zur Sicherheit von Zahlungsseiten vom März 2025 weist zudem darauf hin, dass solche Skripte weitere Skripte von Partnern der Partner nachladen können, und nennt Analyse-, Marketing-, Tag-Management-, Formularprüfungs- und sogar Zahlungswerkzeuge unter denen, die zum Abgreifen von Daten manipuliert werden können.

Eine Fallstudie von Visa zeigt den Multiplikatoreffekt. Die Ermittlung begann mit dem Hinweis einer Bank zu einem einzigen Restaurant, doch der Schadcode steckte in einer legitimen Datei des Online-Bestelldienstes, nicht auf der Website des Restaurants. Dieselbe Datei nutzten viele der mehr als 1.500 Kunden des Dienstes, und ein Drittel von ihnen war kompromittiert. Visa fand die Quelle zehn Tage nach der Infektion.

Was PCI DSS verlangt, einfach erklärt

Anforderung 6.4.3: Inventar, Freigabe und Integrität

Jedes Skript, das auf der Zahlungsseite im Browser des Kunden geladen und ausgeführt wird, braucht drei Dinge:

• Freigabe: ein Verfahren, das bestätigt, dass jedes Skript genehmigt wurde. Der Standard sagt nicht, wie oder von wem; laut dem Leitfaden des PCI SSC kann die Freigabe vor dem Hinzufügen oder Ändern erfolgen oder so bald wie möglich danach, weil Anbieter Dateien ohne Vorwarnung ändern können.
• Integrität: ein Verfahren, das sicherstellt, dass das Skript keine unerlaubten Inhalte enthält: bei der Einführung und bei jedem Update.
• Inventar: eine Liste aller Skripte mit geschäftlicher oder technischer Begründung für jedes. In einfachen Umgebungen, so der Leitfaden, kann eine Tabelle genügen.

Skripte für die 3-D-Secure-Authentifizierung sind von dieser Prüfung ausgenommen. Und ein Anbieter, dessen Skripte nichts mit der Zahlung zu tun haben, gilt für andere Teile des Standards womöglich nicht als Dienstleister. Seine Skripte unterliegen aber weiterhin 6.4.3 und 11.6.1.

Anforderung 11.6.1: Änderungen erkennen

Nötig ist ein Mechanismus, der das Team bei unerlaubten Änderungen alarmiert (Skripte, die auftauchen, sich ändern oder verschwinden, sowie Änderungen an sicherheitsrelevanten Headern), und zwar an der Seite, wie der Browser des Kunden sie erhält. Er muss mindestens wöchentlich laufen oder in einer per gezielter Risikoanalyse festgelegten Frequenz. Das PCI SSC selbst empfiehlt, wo möglich, häufige oder Echtzeit-Überwachung, weil eine bösartige Änderung zwischen zwei Prüfungen unbemerkt wirken kann.

So bauen Sie das Inventar in der Praxis auf

1. Seiten erfassen. Beziehen Sie die Seite ein, die das Formular des Zahlungsdienstleisters anzeigt. Bei Single-Page-Shops, in denen der Browser zwischen den Schritten nicht neu lädt, bleiben früher geladene Skripte bei der Zahlung aktiv, und der Leitfaden zählt alle Ansichten zum Prüfumfang.
2. Erfassen, was der Browser erhält, nicht nur, was im eigenen Code steht: Öffnen Sie die Seite als Kunde, denn Tag-Manager fügen Skripte erst zur Laufzeit hinzu.
3. Jedes Skript dokumentieren: Herkunftsadresse, Anbieter, interne Zuständigkeit, Zweck, Begründung, wer es wann freigegeben hat.
4. Entscheiden: bleibt, fliegt raus oder wandert auf eine andere Seite. Ohne Begründung kein Skript.
5. Integritätsschutz wählen: eine Liste erlaubter Quellen, die Prüfung des Datei-Fingerabdrucks oder ein spezialisiertes Werkzeug. PCI DSS schreibt keine Methode vor.
6. Erwartetes Verhalten festhalten: welche Felder das Skript lesen muss und wohin es Daten sendet.
7. Bei jeder Änderung prüfen, auch bei denen, die der Anbieter eigenmächtig vornimmt.

Was schiefgehen kann

• Die Tabelle veraltet. Ein Inventar, das niemand pflegt, wird zum alten Schnappschuss der Seite.
• Den Anbieter freigeben statt der Version. Die Datei ändert sich auf seinem Server, und die alte Freigabe deckt den neuen Code nicht ab.
• Die Seite rund um das Formular vergessen. Das Formular des Dienstleisters verkleinert den Prüfumfang, doch die Seite, die es anzeigt, bleibt in Ihrer Verantwortung.
• Alarme ohne Zuständigkeit. Wenn der Mechanismus nur warnt und nicht blockiert, betont das PCI SSC, dass schnell reagiert werden muss; legen Sie fest, wer Alarme erhält und wer handelt.
• Das Minimum zum Ziel machen. Eine wöchentliche Prüfung lässt Tage ungeschützt.

Proteside liefert diesen Nachweis, während es schützt: Es erfasst die freigegebenen Skripte auf der Zahlungsseite, prüft im Browser des Käufers, was sich ändert und wohin Daten gehen, und blockiert, was dort nicht hingehört. Sehen Sie sich die Lösung für PCI-DSS-Konformität und den Schutz für Kartenzahlungen an und testen Sie 14 Tage kostenlos.