Prüfpunkt software.cookie.ohne_schutzSitzung, Cookies und Zahlungsdaten
Warenkorb nach der Zahlung leer: woran liegt das?
Kommt ein Kunde vom Zahlungsanbieter oder von der Freigabe in seiner Banking-App zurück und ist abgemeldet, der Warenkorb leer, kann eine Cookie-Einstellung die Ursache sein: Der Rücksprung kommt per POST von einer fremden Adresse, und ein Sitzungscookie mit SameSite=Lax geht dabei nicht mit. Ihr Shop hält den Kunden dann für einen neuen Besucher. Die Abhilfe liegt in der Adresse, an die der Rücksprung geht.
Der Rücksprung per POST kommt ohne Sitzungscookie an
Bei der Sicherheitsabfrage der Bank (3-D Secure) geht das Ergebnis per POST an eine Adresse Ihres Shops; Moneris und Adyen beschreiben das so in ihren Anleitungen. POST ist eine Anfrage, die Daten abschickt. Ein Cookie mit SameSite=Lax schickt der Browser bei Anfragen von fremden Seiten nur bei einem Seitenwechsel per GET mit. POST ist ausgenommen, darin liegt der Schutz des Merkmals. Der Shop sieht also keine Sitzung, legt eine neue an und schickt sie unter demselben Cookienamen zurück. Das überschreibt die alte Sitzung, und der Kunde ist ab jetzt Gast. Der Hersteller Bagisto beschreibt genau diesen Ablauf für Shops auf Laravel; als Fehler bemerkt ihn das System dort nicht.
Chrome lässt junge Cookies zwei Minuten lang durch
Fehlt die SameSite-Angabe, behandelt Chrome das Cookie wie Lax, schickt es aber bei einem solchen POST noch mit, wenn es höchstens 2 Minuten alt ist. Das Chromium-Projekt nennt das eine vorübergehende Lösung, die wieder entfällt. Das kann erklären, warum der Fehler nur manchmal auftritt: Wer rasch bezahlt, kommt durch, wer die Banking-App erst suchen muss, verliert die Sitzung. Ein schneller Test der Agentur zeigt dann nichts.
Der Kunde hat bezahlt und sieht keine Bestellung
Für den Kunden ist das Geld weg und die Bestellung nicht da. Er schreibt, ruft an oder bezahlt ein zweites Mal, und Sie haben eine Rückbuchung mehr zu klären. Hängt die Bestellung an der Sitzung, fehlt sie auch in Ihrer Verwaltung, obwohl das Geld beim Zahlungsanbieter eingegangen ist. Wer das einmal erlebt hat, bestellt beim nächsten Mal vielleicht woanders.
Die Bestellung hängt an der Zahlung, die Sitzung kommt danach
Die Rücksprung-Adresse findet die Bestellung über die Kennung, die der Anbieter mitschickt, legt keine neue Sitzung an und leitet per GET auf die Bestätigungsseite weiter. Dort ist das Lax-Cookie wieder da, und der Kunde ist wie zuvor angemeldet. Die Buchung selbst gehört auf die Meldung, die der Anbieter direkt an Ihren Server schickt (Webhook). Stripe schreibt dazu, dass Webhooks sicherstellen, dass jede Zahlung ausgeführt wird; die Weiterleitung dient dem Kunden.
So gehen Sie es an
- Machen Sie eine echte Testzahlung mit Sicherheitsabfrage und warten Sie vor der Freigabe länger als 2 Minuten.
- Lassen Sie Ihre Agentur in den Entwicklerwerkzeugen nachsehen, ob der Rücksprung per POST kommt und ob die Antwort ein neues Sitzungscookie setzt.
- Fragen Sie Ihren Zahlungsanbieter, ob der Rücksprung auch per GET möglich ist.
- Bitten Sie darum, Bestellungen über die Meldung des Anbieters zu buchen.
Tipps aus der Praxis
- Legen Sie den Warenkorb beim Absprung zur Zahlung als offene Bestellung in der Datenbank an. Dann geht nichts verloren, wenn die Sitzung fehlt.
- Muss die Sitzung schon beim POST wieder da sein, nennt Bagisto einen kurzlebigen, signierten Wert in der Rücksprung-Adresse als Weg.
Mehr zu diesem Thema
Weiter in der Cybersicherheit
- Wie wird eine kleine Website angegriffen?Bekannte Lücken, Anmeldung, Fehlkonfiguration, fremde Skripte: die Wege in kleine Websites nach BSI, ENISA, Verizon und Patchstack. Woran Sie jeden erkennen.
- Was kann ein Angriff auf meiner Website anrichten?Kartendaten aus dem Bestellformular, Besucher auf Betrugsseiten, 20 Millionen Pfund Bußgeld: echte Fälle mit Quelle und dem Merkmal, das den Weg zeigt.
- Wann schützt eine Content-Security-Policy vor eingeschleusten Skripten?Eine Content-Security-Policy legt fest, welche Skripte der Browser ausführt. Sie wirkt, wenn sie Skripte einzeln freigibt statt pauschal.
- Wehrt Ihre Website das Abtasten nach Schwachstellen ab?Am Ende der Prüfung ruft der Messkern typische Scan-Adressen ab und sieht nach, ob Ihr Server danach sperrt. Das Ergebnis steht als Hinweis im Bericht.
Dieser Prüfpunkt gehört zur Cybersicherheit, Unterthema Sitzung, Cookies und Zahlungsdaten. Gemessen wird er im Prüfbereich Aktualität. Was die Prüfung insgesamt leistet, zeigt die Leistungsseite; wie ein Ergebnis zustande kommt, erklärt das Prüfverfahren.
