Direkt zum Inhalt

Cookie-Einstellungen

Wählen Sie, welche Arten von Cookies Sie erlauben. Sie können Ihre Auswahl jederzeit über Cookie-Einstellungen unten auf jeder Seite ändern. Datenschutzerklärung

Notwendig

Immer aktiv

Nötig zum Einloggen, für Ihren Warenkorb und um Ihre Auswahl zu speichern. Diese sind immer aktiv.

Welche Cookies?
  • weboke_sessie, weboke_klant, weboke_remember: Ihre Sitzung und eingeloggt bleiben
  • weboke_basket: Ihr Warenkorb
  • wkBtwIncl: Preise mit oder ohne MwSt. anzeigen
  • wok_cookies: Ihre Cookie-Auswahl, 12 Monate

Misst, welche Anzeige zu einem Besuch oder einer Bestellung führt, damit wir nicht für Anzeigen zahlen, die nichts bringen.

Welche Cookies?
  • Google Ads über Google Tag Manager (_gcl_au, _gcl_aw), bis zu 90 Tage
  • OpenAI Ads, Anzeigen in ChatGPT
  • wok_aff: über welchen Partner Sie zu uns kamen (Partnerprogramm), 60 Tage

4,6

Land und Sprache

Jedes Land hat seine eigene Website, mit Preisen und MwSt. dieses Landes.

Anzeigen

Modul 6 · 6.3

Deutsch

Zahlungssicherheit: PCI und Betrug

Modul 6: Verwaltung und Sicherheit · Lesezeit: 11 Minuten

Lernziel: Nach dieser Lektion können Sie erklären, warum ein Shop Kartendaten nie selbst verarbeitet, was PCI DSS und SAQ A für einen kleinen Shop bedeuten, wie Sie die Kassenseite schützen und wie Sie Betrug und Card Testing erkennen und begrenzen.

Kernbegriffe: PCI DSS, Kartendaten, Zahlungsanbieter, Weiterleitung zur Zahlungsseite, eingebettetes Zahlungsformular (iframe), SAQ A, Skripte auf der Kassenseite, E-Skimming, https, HSTS, Card Testing, Rate Limiting, Captcha, 3-D Secure, Rückbuchung (Chargeback), Betrugsrisiko

Kartendaten gehören nicht in Ihren Shop

Eine Kreditkartennummer, das Ablaufdatum und der Sicherheitscode sind für Kriminelle Gold wert. Wer sie speichert oder weitergibt, fällt unter PCI DSS (Payment Card Industry Data Security Standard), den Sicherheitsstandard der Kartenorganisationen. Die aktuelle Version ist v4.0.1. Für ein Unternehmen, das Kartendaten selbst verarbeitet, ist das ein umfangreiches Paket an Anforderungen: Netzwerktrennung, Protokolle, Scans, Tests durch eine anerkannte Stelle.

Ein kleiner Shop möchte damit nichts zu tun haben, und das muss er auch nicht. Die feste Regel lautet: Kartendaten kommen nie in Ihren Shop. Der Kunde gibt sie bei Ihrem Zahlungsanbieter ein (Mollie, Stripe, PayPal, WooPayments oder ein anderer, Lektion 4.4). Der Shop erfährt danach nur: bezahlt oder nicht, mit einer Referenz. Keine Kartennummer, kein Code. Das bedeutet auch:

  • niemals ein eigenes Formularfeld für Kartennummern anlegen, auch nicht "nur kurz für eine telefonische Bestellung";
  • niemals Kartendaten per E-Mail, Chat oder Telefon entgegennehmen und in eine Notiz zur Bestellung schreiben;
  • kein Plugin verwenden, das Kartendaten in Ihrer eigenen Datenbank speichert.

Weiterleitung oder eingebettet: SAQ A

Kleine Shops weisen mit einem SAQ (Self-Assessment Questionnaire, ein Fragebogen) nach, dass sie PCI DSS einhalten. Ihr Zahlungsanbieter verlangt das manchmal. Der einfachste ist SAQ A, für Shops, die die Zahlung vollständig auslagern. Es gibt zwei Wege, wie das in einem Shop funktioniert:

  1. Weiterleitung. Nach dem Bestellen gelangt der Kunde zur Zahlungsseite des Anbieters und danach zurück. Der Shop sieht die Kartendaten nie, auch nicht die Seite, auf der sie eingegeben werden.
  2. Eingebettetes Formular. Das Zahlungsfeld steht auf Ihrer Kassenseite, ist aber ein iframe (ein Seitenausschnitt) des Anbieters. Die Kartendaten gehen vom Browser direkt an den Anbieter.

Seit dem 31. März 2025 gilt eine neue Version von SAQ A. Darin steht eine Bedingung, die vor allem den zweiten Weg betrifft: Wer ein eingebettetes Formular verwendet, muss bestätigen, dass seine Website nicht anfällig für Angriffe mit Skripten ist, die das Zahlungssystem treffen können. Hintergrund ist E-Skimming: ein bösartiges Skript auf Ihrer Kassenseite, das mitliest, was der Kunde eingibt, oder ein gefälschtes Zahlungsfeld über das echte legt. Wer zur Seite des Anbieters weiterleitet, fällt nicht unter diese Bedingung. Fragen Sie Ihren Zahlungsanbieter, welcher SAQ für Ihre Anbindung gilt; er weiß es genau.

Was Sie auf jeden Fall tun:

  • Halten Sie die Kassenseite schlank. Jedes Skript auf dieser Seite kann grundsätzlich mitlesen: Chat-Widgets, Tag-Manager, Werbepixel, A/B-Test-Tools. Laden Sie auf der Kassenseite nur, was für die Zahlung nötig ist. Ein Tag-Manager auf der Kassenseite ist ein Tor, durch das jeder mit Zugang zu diesem Konto Skripte hinzufügen kann.
  • Wenige Plugins, und aktuell (Lektion 6.2). Das meiste E-Skimming bei WordPress gelangt über eine Sicherheitslücke in einem Plugin oder ein gestohlenes Administratorpasswort hinein.
  • Eine Content-Security-Policy (ein Header, der festlegt, von welchen Domains Skripte stammen dürfen) begrenzt den Schaden, falls doch etwas eindringt. Das ist Arbeit für jemanden, der es testen kann; eine falsche CSP legt Ihren Zahlungsbutton lahm.

https und HSTS auf der Kassenseite

Dass Ihr gesamter Shop über https läuft, ist selbstverständlich (WordPress-Kurs, Lektion 3.1). Für die Kassenseite kommen zwei Dinge hinzu:

  • http muss sofort auf https weiterleiten, mit einer dauerhaften Weiterleitung (301 oder 308). Ein Kunde, der irgendwann http://shop.example.com/afrekenen/ eingibt, darf keine unverschlüsselte Seite erhalten.
  • HSTS (HTTP Strict Transport Security) ist ein Header, mit dem Sie den Browser anweisen, Ihre Website für eine bestimmte Zeit nur über https zu öffnen. So verhindern Sie, dass jemand in einem offenen WLAN die erste unverschlüsselte Anfrage abfängt. Ein max-age von mindestens 180 Tagen ist ein übliches Minimum. Aktivieren Sie HSTS erst, wenn alles, auch Subdomains, die Sie einbeziehen, über https funktioniert: Ein Browser, der HSTS gesehen hat, verweigert danach http. KB 6752 erklärt, wie Sie es einrichten.

Gemischte Inhalte (ein Skript oder Stylesheet über http auf einer https-Seite) sind auf der Kassenseite besonders gefährlich: Genau eine solche Datei kann unterwegs ausgetauscht werden.

Card Testing

Beim Card Testing nutzen Kriminelle Ihren Shop, um gestohlene Kartennummern auszuprobieren. Sie geben automatisch Hunderte kleiner Bestellungen auf. Jede erfolgreiche Zahlung verrät ihnen, dass eine Karte funktioniert. Sie erhalten einen Stapel fehlgeschlagener Bestellungen, Kosten pro Transaktion, Rückbuchungen und im schlimmsten Fall einen Zahlungsanbieter, der Ihr Konto sperrt.

Erkennen: viele Bestellungen in kurzer Zeit, oft desselben kleinen Produkts, mit verschiedenen Namen, aber gleichen oder seltsamen Adressen, und viele mit dem Status Fehlgeschlagen.

Begrenzen:

  • Rate Limiting (eine Grenze für die Anzahl der Anfragen pro Zeitraum). Die Store API von WooCommerce, die von den Blöcken für Warenkorb und Kasse verwendet wird, hat Rate Limiting eingebaut, das aber standardmäßig ausgeschaltet ist. Unter WooCommerce > Einstellungen > Erweitert > Funktionen können Sie "Rate limiting Checkout block and Store API" für das Aufgeben von Bestellungen aktivieren. Mit Code (einem Filter) können Sie die Grenze selbst festlegen; der Standard liegt bei 25 Anfragen pro 10 Sekunden, und nur Bestellungen und andere schreibende Aktionen zählen. Steht Ihr Shop hinter einem Proxy oder CDN, muss die Proxy-Unterstützung aktiviert sein, sonst zählen alle Besucher als einer.
  • Ein Captcha oder eine vergleichbare Hürde an der Kasse. WooCommerce sagt selbst, dass Rate Limiting und Captcha zusammen am besten wirken: Angreifer wechseln häufig die IP-Adresse.
  • Die Einstellungen Ihres Zahlungsanbieters. Anbieter haben eigene Betrugsfilter und Limits. Aktivieren Sie diese und prüfen Sie, was sie melden.
  • 3-D Secure (die zusätzliche Bestätigung in der Banking-App, Teil der starken Kundenauthentifizierung in der EU) erschwert es Kriminellen und verlagert bei einem Streitfall oft die Haftung auf die Bank des Karteninhabers.

Anderer Betrug

Nicht jeder Betrug ist automatisiert. Signale, die zusammengenommen ein Grund sind, mit dem Versand kurz zu warten:

  • Rechnungs- und Lieferadresse in verschiedenen Ländern oder eine Lieferadresse bei einem Weiterleitungsdienst;
  • eine erste Bestellung mit ausschließlich teuren, leicht weiterverkäuflichen Produkten und Expressversand;
  • mehrere Versuche mit verschiedenen Karten;
  • ein Kunde, der nach der Zahlung bittet, an eine andere Adresse zu liefern.

Eine Rückbuchung (Chargeback) ist die Rückabwicklung einer Kartenzahlung durch die Bank des Kunden. Sie verlieren den Betrag, oft zuzüglich Gebühren, und das Produkt ist weg. Bewahren Sie deshalb Nachweise über Versand und Zustellung auf. Eine iDEAL-Zahlung in den Niederlanden konnte bisher nicht auf diese Weise rückgängig gemacht werden; wie das bei Wero läuft, erfahren Sie von Ihrem Zahlungsanbieter (Lektion 4.4). In Deutschland sind unter anderem PayPal, Klarna (früher SOFORT), Kreditkarte, Kauf auf Rechnung und Lastschrift gängig; wie Rückbuchungen dabei ablaufen, erfahren Sie ebenfalls von Ihrem Zahlungsanbieter.

Zusammenfassung

  • Kartendaten kommen nie in Ihren Shop: nicht in Formulare, Notizen oder E-Mails. Der Zahlungsanbieter verarbeitet sie.
  • Die Weiterleitung zur Zahlungsseite oder ein eingebettetes Feld des Anbieters hält Sie beim einfachsten PCI-Fragebogen (SAQ A); bei einem eingebetteten Feld muss Ihre Kassenseite gegen Skriptangriffe geschützt sein.
  • Halten Sie die Kassenseite schlank, über https mit einer 301 von http und mit HSTS von mindestens 180 Tagen.
  • Card Testing begrenzen Sie mit Rate Limiting (standardmäßig aus), einem Captcha und den Filtern Ihres Anbieters.
  • Achten Sie auf Betrugssignale und bewahren Sie Zustellnachweise gegen Rückbuchungen auf.

Quiz

1. Ein Kunde ruft an und möchte seine Kartendaten für eine Bestellung durchgeben. Was tun Sie?



2. Warum ist ein Tag-Manager auf der Kassenseite ein Risiko?



3. In einer Nacht gehen 300 Bestellungen eines Produkts zu € 2 ein, die meisten mit dem Status Fehlgeschlagen. Was passiert wahrscheinlich?



4. Ist das Rate Limiting der Store API standardmäßig aktiviert?



Aufgabe

Aufgabe A6.3: Ist Ihre Kassenseite sicher? Geben Sie die Adresse Ihres Shops und die Adresse Ihrer Kassenseite ein. Das Programm prüft das Zertifikat und ruft die Kassenseite über http (ohne Weiterleitung zu folgen) und über https auf (mit leerem Warenkorb, es wird nichts bestellt). Grün, wenn das Zertifikat gültig ist, http mit 301 oder 308 auf https weiterleitet, der Header Strict-Transport-Security ein max-age von mindestens 180 Tagen hat, keine gemischten Inhalte vorhanden sind und höchstens fünf fremde Domains Skripte auf der Seite laden (das Programm zeigt sie an). Orange bei fehlendem oder zu kurzem HSTS, einer vorübergehenden Weiterleitung (302 oder 307), mehr als fünf Skriptdomains oder einem Tag-Manager oder einem Kartennummernfeld im eigenen HTML statt beim Anbieter. Rot, wenn https oder das Zertifikat nicht stimmt, http nicht weiterleitet oder Skripte oder Stylesheets über http geladen werden. Speichern Sie Kartendaten nie selbst. Diese Prüfung sieht nur, was ohne Warenkorb auf der Seite steht.

Frage für Sie selbst (wird nicht ausgewertet): Leitet Ihr Zahlungs-Plugin zum Anbieter weiter, oder steht das Zahlungsfeld auf Ihrer Seite? Welcher SAQ gilt laut Ihrem Anbieter?

Ein grünes Häkchen bedeutet, dass diese Prüfung jetzt stimmt, nicht dass Ihr Shop sicher ist.

Aufgabe A6.3: Ist Ihre Kassenseite sicher?



Was Sie eingeben und was wir finden, speichern wir nicht. Ihr Browser merkt sich Ihre Antworten und ob Sie die Aufgabe bestanden haben. Sind Sie angemeldet, speichern wir in Meine Kurse nur, dass Sie die Aufgabe (fast) richtig hatten; auch das können Sie dort löschen.

Weiterführende Informationen

Schritte in einem Panel gelten für WebOké; bei anderen Anbietern funktioniert es ähnlich.

Einen Moment bitte…

Richten Sie Ihre Domains ein

Legen Sie für jede Domain die Nameserver, die Verknüpfung mit Ihrem Hosting und den künftigen Inhaber fest.

Ihre Domains werden geladen…