Zahlungen über Webhooks: doppelte Rechnungen und eine ungeprüfte Signatur

Nach der Zahlung über Stripe Checkout schickt Stripe das Ereignis checkout.session.completed an /webhooks/stripe. Die Anwendung sucht die Bestellung, markiert sie als bezahlt, schaltet den Kurs frei, erzeugt eine PDF-Rechnung und verschickt sie per E-Mail. Alles in einer Anfrage, während Stripe auf die Antwort wartet.

Die Signaturprüfung war ursprünglich im Code, funktionierte aber nicht, und der Entwickler schaltete sie ab. Die Anwendung nutzte express.json() global, das den Anfragekörper parst, bevor die Prüfung ihn zu sehen bekommt.

Beim Monatsabschluss fiel der Buchhaltung auf, dass manche Kunden für eine Zahlung zwei oder drei Rechnungen mit verschiedenen Nummern hatten. Kunden fragten, warum sie mehrere bekommen hatten.

Bei der Ursachensuche stieß der Entwickler auf die abgeschaltete Signaturprüfung, das ernstere Problem. Wer die Webhook-Adresse kannte (und /webhooks/stripe ist leicht zu erraten), konnte ein eigenes Ereignis checkout.session.completed mit der ID seiner unbezahlten Bestellung schicken, und die Anwendung schaltete den Kurs frei.

Voraussetzung: Der Angreifer legt eine Bestellung an, ohne zu zahlen, und schickt ein gefälschtes Ereignis. Mehr als einen Browser und ein Werkzeug für HTTP-Anfragen braucht er nicht.

Stripe liefert Ereignisse mindestens einmal, nicht genau einmal. Kommt nicht rechtzeitig ein 2xx, versucht Stripe es erneut, im Live-Modus bis zu drei Tage, und dasselbe Ereignis kann auch ohne Fehler beim Empfänger mehrfach ankommen. Die Verarbeitung war nicht idempotent: Jede Zustellung stellte eine neue Rechnung aus.

Die Verarbeitung war langsam, weil sie während der Anfrage das PDF erzeugte und die E-Mail verschickte. Dauerte es zu lange, wertete Stripe das als Fehlschlag und schickte das Ereignis erneut, oft noch während der erste Durchlauf lief.

Die Signatur wird über die exakten Bytes des Anfragekörpers berechnet, stripe.webhooks.constructEvent braucht den Körper also unverändert. Nach express.json() bekommt es ein Objekt, die Prüfung scheitert, und statt die Reihenfolge der Middleware zu korrigieren, wurde die Prüfung abgeschaltet.

Die Webhook-Übersicht in Stripe zeigt zu jedem Ereignis alle Zustellversuche und die Antworten der Anwendung. Die doppelten Rechnungen passten zu Ereignissen mit mehreren Versuchen, bei denen der erste in den Timeout gelaufen war.

Ob jemand die fehlende Signatur ausgenutzt hatte: Ein Skript ging alle bezahlten Bestellungen durch, holte über die Stripe-API die zugehörige Checkout Session und prüfte, dass payment_status gleich paid ist und der Betrag zur Bestellung passt. Es fand keine Abweichung.

Der Webhook hat eine eigene Route mit express.raw(), registriert vor dem globalen express.json(), und prüft die Signatur. Jedes Ereignis wird in einer Transaktion in eine Tabelle mit eindeutiger ID geschrieben. Steht es schon dort, passiert nichts.

// registered BEFORE app.use(express.json()): the signature covers the raw bytes
app.post("/webhooks/stripe", express.raw({ type: "application/json" }), async (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.body,
      req.headers["stripe-signature"],
      process.env.STRIPE_WEBHOOK_SECRET,
    );
  } catch {
    return res.sendStatus(400); // unsigned or altered: not from Stripe
  }

  const client = await pool.connect();
  try {
    await client.query("BEGIN");
    // delivery is at least once: the event id is the idempotency key
    const first = await client.query(
      "INSERT INTO stripe_events (id) VALUES ($1) ON CONFLICT (id) DO NOTHING",
      [event.id],
    );
    if (first.rowCount === 1) await handleEvent(client, event);
    await client.query("COMMIT");
  } catch (err) {
    await client.query("ROLLBACK");
    throw err; // 500: Stripe retries later (Express 5 forwards the rejection)
  } finally {
    client.release();
  }

  res.sendStatus(200);
});

Die eigentliche Verarbeitung markiert die Bestellung nur über ein bedingtes UPDATE als bezahlt, und nur bei passendem Betrag. Rechnung und E-Mail entstehen nicht mehr während der Anfrage: In derselben Transaktion entsteht ein Eintrag in der Tabelle outbox, den ein eigener, minütlich per cron gestarteter Prozess verschickt.

-- inside the same transaction as the event insert
UPDATE orders
   SET status = 'paid', paid_at = now()
 WHERE id = $1 AND status = 'pending' AND amount_cents = $2;

-- only when that UPDATE touched a row: the invoice email waits in an outbox
INSERT INTO outbox (kind, order_id) VALUES ('invoice_email', $1);

Bei checkout.session.completed wird auch payment_status geprüft. Bei Zahlarten mit verzögerter Bestätigung kann er noch unpaid sein, die Bestellung wird dann erst mit checkout.session.async_payment_succeeded abgeschlossen.

Nächtlicher Abgleich: Ein Skript vergleicht die Bestellungen der letzten Tage mit der Liste der Checkout Sessions in Stripe. Es fängt auch ein Ereignis ab, das Stripe innerhalb seiner drei Tage nicht zustellen konnte.

Die doppelten Rechnungen korrigierte die Buchhaltung mit Gutschriften. Eine ausgestellte Rechnung lässt sich nicht einfach löschen.

Die Signatur belegt, dass das Ereignis von Stripe stammt und unterwegs nicht verändert wurde. Ohne das Webhook-Geheimnis lässt sich keine gültige Signatur erzeugen, ein gefälschtes Ereignis endet mit 400.

Die eindeutige Ereignis-ID in der Datenbank macht eine wiederholte Zustellung harmlos. Kommen zwei Kopien gleichzeitig, wartet das zweite INSERT, bis die erste Transaktion fertig ist, und fügt dank ON CONFLICT DO NOTHING dann nichts ein.

Das bedingte UPDATE ist eine zweite Sicherung: Es ändert keine Bestellung, die nicht mehr pending ist, und akzeptiert keinen abweichenden Betrag.

Die Antwort kommt schnell, weil PDF und E-Mail außerhalb der Anfrage entstehen, Stripe wiederholt also nicht unnötig. Der outbox-Eintrag entsteht in derselben Transaktion wie die Zahlung, die E-Mail geht also auch dann nicht verloren, wenn die Anwendung direkt danach abstürzt.

Was das nicht löst: Der Prozess, der die outbox verschickt, kann eine E-Mail doppelt senden, wenn er zwischen Versand und Vermerk abstürzt. Die Rechnung selbst wird aber nicht doppelt ausgestellt, sie entsteht nur einmal.