Integration Ihres Shops in den KI-Chat mit UCP: Was Sie wissen müssen

Was ist UCP und warum sollte ich mich dafür interessieren?

Ihr Geschäft erwägt also eine Integration mit dem Universal Commerce Protocol (UCP), über das KI-Plattformen und Chat-Dienste eine Verbindung zu Ihrem Geschäft herstellen können, um Inventar und Verkäufe zu tätigen. Das ist klug - es eröffnet neue Vertriebskanäle. Doch bevor Sie sich darauf einlassen, lassen Sie uns darüber sprechen, was schief gehen kann und worauf Sie achten müssen.

Stellen Sie sich UCP so vor, als ob Sie einem vertrauenswürdigen Freund Zugang zu Ihrer Kasse geben. Sie wollen sichergehen:

1. Nur tatsächlich vertrauenswürdige Freunde erhalten Zugang
2. Sie können nicht die Preise ändern oder aus der Schublade stehlen
3. Wenn sie mit Geld umgehen, tun sie es sicher.

Die Sache ist die, dass "vertrauenswürdige Freunde" kompromittiert werden können. Eine Plattform, der Sie vertrauen, könnte gehackt werden. Oder ein böswilliger Benutzer könnte versuchen, den Kassiervorgang zu exploitieren. Lassen Sie mich Ihnen einige echte Sicherheitsbedenken erläutern.

Die grundlegende Einrichtung: Wie UCP funktioniert

Wenn Sie UCP integrieren, sagen Sie damit im Wesentlichen: "Hey Plattformen, hier ist meine Checkout-API. Benutzt sie, um meine Sachen zu verkaufen."

Das passiert folgendermaßen:

1. Eine Plattform entdeckt Sie - Sie schaut sich Ihren /.well-known/ucp Endpunkt an, um zu sehen, was Sie unterstützen (Kasse, Bestellungen, Zahlungsabwicklung usw.)
2. Sie einigen sich auf Fähigkeiten - Sie und die Plattform handeln aus, welche Funktionen Sie beide unterstützen.
3. Sie leiten die Kaufabwicklung ein - Ein Kunde legt Ihr Produkt über Google Chat oder einen KI-Agenten in seinen Warenkorb
4. Sie wickeln die Zahlung ab - Die Plattform sendet Ihnen die Zahlungsinformationen (als Token, nicht in Form von Kartennummern), und Sie verarbeiten sie.
5. Sie senden Updates - Sie teilen der Plattform mit, wann die Bestellung versandt wird, eintrifft usw.

Sie behalten die Kontrolle. Sie sind immer noch der Händler. Die Plattform erleichtert nur die Kaufabwicklung.

Wie sich Plattformen mit Ihnen verbinden:

UCP unterstützt mehrere Protokolle, über die Plattformen mit Ihnen kommunizieren können:

• REST/HTTPS - Standard-HTTP-API
• MCP - Für LLM-Agenten über JSON-RPC
• A2A - Kommunikation von Agent zu Agent
• Embedded Checkout (ECP) - Checkout UI direkt in eine Host-Anwendung eingebettet

Alle diese Lösungen verwenden die Authentifizierung mit einem Inhaber-Token und validieren Plattformprofile. Der Unterschied ist das Protokollformat, nicht der Sicherheitsmechanismus.

Bedrohung 1: Manipulation des Kassenflusses

Das Szenario: Ein böswilliger Benutzer ODER eine kompromittierte Plattform manipuliert den Checkout-Flow und ändert:

• Den Preis (berechnet $5 statt $50)
• Die Menge (bestellt 1.000 Artikel statt 1)
• Die Lieferadresse (sendet an die eigene Adresse statt an die des Kunden)
• Die Bestellsumme oder Rabatte

Dies kann zu Umsatzeinbußen, falscher Abwicklung oder Betrug führen.

Wie UCP hilft:

UCP verwendet ein Konzept namens Binding. Wenn die Zahlungsinformationen eines Kunden erfasst werden, werden sie mit einer eindeutigen ID an eine bestimmte Kassensitzung gebunden. Diese ID ist in das Zahlungs-Token eingebettet. Wenn Sie die Zahlung verarbeiten, überprüfen Sie, ob die Kassen-ID des Tokens mit der aktuellen Bestellung übereinstimmt.

Es ist wie eine Quittung, auf der steht: "Diese Zahlung ist nur für die Bestellung #ABC123. Verwenden Sie sie nicht für die Bestellung #XYZ789."

Hier ist der Ablauf:

1. Die Plattform initiiert eine Checkout-Sitzung mit Ihnen
2. Sie geben ein Checkout-Objekt mit Zahlungsabwicklung und Konfiguration zurück
3. Die Plattform sammelt die Anmeldedaten des Kunden über einen konformen Anbieter von Zahlungsdaten
4. Die Anmeldedaten sind tokenisiert oder verschlüsselt und an die spezifische checkout_id gebunden.
5. Die Plattform sendet das Token zusammen mit der Checkout-ID ab, um die Bestellung abzuschließen
6. Sie überprüfen, ob die Bindung des Tokens mit der aktuellen Kasse übereinstimmt

Was Sie tun müssen:

1. Überprüfen Sie die Bindung bei jeder Zahlung - Prüfen Sie, ob die checkout_id des Tokens mit Ihrer aktuellen Kasse übereinstimmt. Wenn eine böswillige Plattform versucht, ein Token von Kasse A für Kasse B zu verwenden, sollte dies fehlschlagen.
2. Legen Sie den Ablauf von Token fest - Token sollten nur 5-30 Minuten gültig sein. Danach verfallen sie und können nicht wiederverwendet werden. Wenn ein Token zu lange im Umlauf ist, hat ein Angreifer mehr Zeit, ihn zu exploiten.
3. Erzwingen Sie die einmalige Verwendung - Im Idealfall sollte ein Token nur einmal funktionieren. Nach der ersten Verwendung ist er ungültig. Dies verhindert, dass Angreifer ein gültiges Token bei mehreren Checkouts wiederverwenden.
4. Überprüfen Sie die Konfiguration der Zahlungsabwicklung - Bevor Sie eine Zahlung über eine Zahlungsabwicklung (z.B. Google Pay) akzeptieren, überprüfen Sie, ob die Konfiguration der Zahlungsabwicklung mit dem übereinstimmt, was Sie angekündigt haben. Ein falsch konfigurierter oder gefälschter Handler könnte die Zahlungen auf das Konto eines Angreifers umleiten.
5. Prüfen Sie, ob die Details der Kasse übereinstimmen - Wenn eine Plattform eine vollständige Kassenanfrage sendet, prüfen Sie, ob sich die Artikel, Preise und Summen seit der Erstellung der Kasse nicht geändert haben. Eine böswillige Plattform oder ein böswilliger Benutzer könnte versuchen, eine Kasse mit anderen Preisen abzusenden, als Sie genehmigt haben.

Bedrohung 2: Bösartige Plattformen, die gefälschte Daten senden

Das Szenario: Eine gefährdete oder böswillige Plattform sendet gefälschte Bestellungsereignisse (Webhooks) an Sie und behauptet, dass Bestellungen aufgegeben, versandt oder erstattet wurden, obwohl dies nicht der Fall war. Dies kann zu folgenden Problemen führen:

• Falsche Bestandszählungen
• Betrügerische Rückerstattungen
• Verwirrte Kundendaten
• Umsatzeinbußen

Wie UCP hilft:

UCP verlangt von den Plattformen, dass sie alle Webhook-Nutzdaten kryptografisch signieren. Wenn Sie einen Webhook erhalten, können Sie die Signatur mithilfe des öffentlichen Schlüssels der Plattform überprüfen. Wenn die Signatur ungültig ist, ist der Webhook gefälscht.

Das ist so, als würden Sie die Unterschrift auf einem Scheck überprüfen - wenn sie nicht übereinstimmt, lösen Sie ihn nicht ein.

Was Sie tun müssen:

• Überprüfen Sie die Signaturen aller Webhooks - Überspringen Sie diesen Schritt nicht. Wenn eine bösartige Plattform versucht, gefälschte Auftragsereignisse zu senden, oder wenn ein Angreifer einen Webhook abfängt und verändert, ist die Signatur ungültig. Testen Sie mit einer ungültigen Signatur - sie sollte fehlschlagen.
• Akzeptieren Sie nur Signaturen aus einer zulässigen Liste unterstützter Algorithmen - Definieren Sie, welche Algorithmen Ihr System für Webhook-Signaturen unterstützt und lehnen Sie jede Signatur ab, die einen anderen Algorithmus verwendet. Dies verhindert Algorithmus-Verwechslungsangriffe und andere JWT-Schwachstellen. Testen Sie mit einem nicht unterstützten Algorithmus - er sollte fehlschlagen.
• Verwenden Sie den richtigen Schlüssel zur Verifizierung - Überprüfen Sie den Kid (Schlüssel-ID) im Signatur-Header, um den richtigen öffentlichen Schlüssel aus dem Profil der Plattform zu finden. Wenn Sie den falschen Schlüssel verwenden, schlägt die Überprüfung fehl. Testen Sie mit einer Signatur von der falschen Plattform - sie sollte fehlschlagen.
• Abgelaufene Signaturen ablehnen - Signaturen sollten eine Ablaufzeit haben. Akzeptieren Sie keine Signaturen, die älter als ein angemessener Schwellenwert sind. Testen Sie mit einer abgelaufenen Signatur - sie sollte fehlschlagen.

Bedrohung 3: Nicht autorisierte Operationen

Das Szenario: Eine böswillige Plattform oder ein böswilliger Benutzer versucht, Operationen in Ihrem Shop durchzuführen, die er nicht durchführen sollte:

• Zugriff auf Kassensitzungen, die er nicht erstellt hat
• Anfordern von Funktionen, die Sie nicht unterstützen
• Verwendung abgelaufener oder ungültiger Anmeldedaten
• Operationen mit dem Token einer anderen Person durchführen

Wie UCP hilft:

UCP verwendet zwei Mechanismen, um nicht autorisierte Operationen zu verhindern:

1. Authentifizierung des Inhaber-Tokens - Plattformen müssen bei jeder Anfrage ein gültiges Inhaber-Token angeben. Ungültige oder abgelaufene Token werden zurückgewiesen.

Hinweis: ECP erlaubt die Verwendung jedes gängigen Authentifizierungsformats, nicht nur Bearer Tokens. Es gelten jedoch die gleichen Sicherheitsüberlegungen.

2. Capability Negotiation - Sie und die Plattform vereinbaren, welche Operationen erlaubt sind. Wenn eine Plattform etwas anfordert, das Sie nicht unterstützen, wird es abgelehnt.

Das müssen Sie tun:

1. Überprüfen Sie die Inhaber-Token bei jeder Anfrage - Stellen Sie sicher, dass das Token gültig und nicht abgelaufen ist und zu einer autorisierten Plattform gehört. Testen Sie mit einem ungültigen Token - er sollte fehlschlagen. Testen Sie mit einem abgelaufenen Token - er sollte fehlschlagen.
2. Fehlerhafte Token zurückweisen - Wenn ein Token nicht dem erwarteten Format entspricht, weisen Sie ihn zurück. Der Test mit einem fehlerhaften Token sollte fehlschlagen.
3. Verwenden Sie nur HTTPS - Bearer-Token sind nur über HTTPS sicher. Akzeptieren Sie niemals Bearer-Token über einfaches HTTP. Dies verhindert das Abfangen von Token.
4. Validieren Sie das Profil der Plattform - Holen Sie vor der Verarbeitung von Anfragen das Profil der Plattform aus dem von ihr bereitgestellten URI und validieren Sie es. Testen Sie, indem Sie ein bösartiges Profil bereitstellen - es sollte abgelehnt oder sicher behandelt werden.
5. Berechnen Sie die Schnittmenge der Fähigkeiten korrekt - Lassen Sie nur Operationen zu, die sich in der Schnittmenge Ihrer und der Fähigkeiten der Plattform befinden. Testen Sie, indem Sie eine nicht unterstützte Operation anfordern - sie sollte fehlschlagen.
6. Lehnen Sie nicht unterstützte Operationen ab - Wenn eine Plattform etwas anfordert, das Sie nicht unterstützen, lehnen Sie es mit einer klaren Fehlermeldung ab. Testen Sie, indem Sie einen Vorgang anfordern, den Sie nicht anbieten - er sollte fehlschlagen.
7. Behandlung von Versionsunterschieden - Wenn eine Plattform eine neuere Version von UCP verwendet, als von Ihnen unterstützt wird, behandeln Sie dies angemessen (in der Regel durch Ablehnung der Anfrage). Testen Sie, indem Sie eine Verbindung mit einer nicht unterstützten Version herstellen - sie sollte fehlschlagen.

Bedrohung 4: Exploit für eingebettete Checkouts

Das Szenario: Stellen Sie sich vor, Sie betten ein Kassenformular direkt in eine Host-Anwendung ein, z.B. einen Kiosk, eine mobile App oder eine Website. Die Host-Anwendung kommuniziert mit Ihrer Kasse über Nachrichten. Ein böswilliger Benutzer oder Angreifer könnte:

• Die Zahlung auslösen, ohne dass der Kunde auf "Bestätigen" drückt
• aus der Sandbox ausbrechen und auf sensible Daten zugreifen
• bösartige Skripte einschleusen
• Zahlungsanmeldedaten oder Kundendaten stehlen

Dies könnte zu nicht autorisierten Abbuchungen, Datendiebstahl oder Betrug führen.

Wie UCP hilft:

Das Embedded Checkout Protocol (ECP) von UCP ist so konzipiert, dass es in einer Sandbox untergebracht ist, d.h. nur den Checkout abwickelt und nicht auf andere Daten zugreift oder Aktionen ohne Genehmigung auslöst. Dies erfordert jedoch eine sorgfältige Konfiguration.

Was Sie tun müssen:

1. Sandbox für die eingebettete Kasse - Schränken Sie ein, was die eingebettete Kasse tun kann. Sie sollte nur die Kasse bedienen, nicht im Internet surfen oder auf andere Daten zugreifen. Testen Sie, indem Sie versuchen, auf Daten außerhalb der Kasse zuzugreifen - dies sollte blockiert werden.
2. Verwenden Sie Content Security Policy (CSP) - Teilen Sie dem Browser mit, welche Ressourcen die Kasse laden und was sie tun kann. Dies verhindert, dass eingeschleuste Skripte ausgeführt werden. Testen Sie, indem Sie versuchen, ein Skript einzuschleusen - es sollte von der CSP blockiert werden.
3. Erfordern Sie eine Bestätigung des Hosts vor der Zahlung - Die Host-App muss die Zahlung bestätigen, bevor sie die Zahlungsinformationen freigibt. Keine stillen Zahlungen. Wenn die eingebettete Kasse versucht, die Zahlung ohne die Zustimmung des Hosts auszulösen, sollte sie fehlschlagen. Testen Sie, indem Sie die eingebettete Kasse versuchen lassen, die Zahlung stillschweigend auszulösen - sie sollte fehlschlagen.
4. Überprüfen Sie die Herkunft von Nachrichten - Akzeptieren Sie nur Nachrichten von vertrauenswürdigen Absendern. Wenn eine Nachricht von einem unerwarteten Absender kommt, weisen Sie sie zurück. Testen Sie, indem Sie eine Nachricht von einem nicht vertrauenswürdigen Absender senden - sie sollte zurückgewiesen werden.

Bedrohung 5: Betrug durch autonome Agenten

Das Szenario: Ein KI-Agent tätigt einen Kauf im Namen eines Kunden ohne ordnungsgemäße Autorisierung, oder ein Angreifer manipuliert einen autonomen Kauf, um:

• den falschen Betrag in Rechnung zu stellen
• Bestellung an die falsche Adresse
• Artikel nach der Autorisierung zu ändern
• den Nachweis der Zustimmung des Kunden zu fälschen

Wie UCP hilft:

Die AP2-Mandatserweiterung von UCP bietet einen kryptografischen Nachweis der Autorisierung. Sowohl Sie als auch der Agent unterzeichnen die Checkout-Bedingungen und erstellen so einen fälschungssicheren Nachweis über die erteilten Genehmigungen.

Es ist wie ein von beiden Parteien unterzeichneter Vertrag - wenn jemand versucht, die Bedingungen zu ändern, stimmen die Unterschriften nicht mehr überein.

Was Sie tun müssen:

1. Überprüfen Sie Signaturen mit dem richtigen Algorithmus - Akzeptieren Sie nur ES256, ES384 oder ES512, wie von UCP angegeben. Weisen Sie jede Signatur zurück, die einen anderen Algorithmus verwendet, einschließlich alg:"keine". Dies verhindert Algorithmus-Verwechslungsangriffe und andere JWT-Schwachstellen. Testen Sie mit einem nicht unterstützten Algorithmus - er sollte fehlschlagen.
2. Ungültige Signaturen zurückweisen - Wenn eine Signatur nicht übereinstimmt, weisen Sie die Zahlung zurück. Testen Sie mit einer ungültigen Signatur - sie sollte fehlschlagen.
3. Stellen Sie sicher, dass die Signatur die richtigen Daten abdeckt - Überprüfen Sie, ob die Signatur die Bedingungen der Kasse abdeckt und nicht entfernt oder verändert wurde. Testen Sie, indem Sie die Details der Kasse nach der Unterzeichnung ändern - die Überprüfung sollte fehlschlagen.
4. Gehen Sie mit der Schlüsselrotation sorgfältig um - Wenn Sie Ihre Signaturschlüssel aktualisieren, stellen Sie sicher, dass alte Signaturen noch eine gewisse Zeit lang verifiziert werden. Testen Sie mit einem abgelaufenen Schlüssel - die Prüfung sollte fehlschlagen (oder erfolgreich sein, wenn sie innerhalb der Schonfrist liegt, je nach Ihrer Richtlinie).
5. Überprüfen Sie die Konfiguration des Handlers - Bevor Sie eine Zahlung über einen Handler akzeptieren, der von einem autonomen Agenten verwendet wird, überprüfen Sie, ob die Konfiguration des Handlers rechtmäßig ist. Ein falsch konfigurierter Handler könnte Zahlungen auf das Konto eines Angreifers umleiten. Testen Sie mit einer bösartigen Handler-Konfiguration - sie sollte abgelehnt werden.

Umgang mit Zahlungsdaten: Kennen Sie Ihr Modell

UCP ist so konzipiert, dass Sie nie mit rohen Kartennummern arbeiten. Stattdessen arbeiten Sie mit Token. Es gibt jedoch verschiedene Modelle, und jedes hat unterschiedliche Auswirkungen auf die Sicherheit und die Komplexität für Ihr Unternehmen:

Option 1: Ihr Zahlungsabwickler (PSP) führt den Tokenizer aus

• Ihr PSP kümmert sich um die rohen Kartennummern und die Tokenisierung (der PSP muss PCI-DSS-konform sein)
• Sie erhalten nur Token, niemals rohe Anmeldedaten
• Weder Sie noch die Plattform müssen PCI-DSS-konform sein
• Dies ist die geringste Compliance-Belastung für Ihr Unternehmen

Option 2: Die Plattform verschlüsselt für Sie

• Die Plattform verschlüsselt die Karte mit Ihrem öffentlichen Schlüssel
• Sie entschlüsseln sie lokal (Sie werden PCI-DSS-konform)
• Sie verwalten die Verschlüsselungsschlüssel sicher und rotieren sie regelmäßig

Option 3: Die Plattform führt den Tokenizer aus

• Der Zahlungsanbieter der Plattform verarbeitet die rohen Kartennummern
• Sie rufen den Endpunkt /detokenize auf, um die Kartendaten abzurufen, wenn Sie abrechnen möchten.
• Sie müssen PCI-DSS-konform sein, um Kartendaten zu erhalten.
• Der Anbieter der Anmeldedaten der Plattform muss PCI-DSS-konform sein.
• Nur eingegliederte Unternehmen können /detokenizeaufrufen - überprüfen Sie, obdies erzwungen wird

Option 4: Sie führen den Tokenizer aus (am komplexesten)

• Sie erhalten rohe Kartennummern (Sie werden PCI-DSS-konform, was teuer und komplex ist)
• Sie generieren Token, die die Plattformen verwenden können
• Token sollten einmalig oder kurzlebig sein, um eine Wiederverwendung zu verhindern

Aktionspunkt: Machen Sie sich klar, welches Modell Sie verwenden und welche Compliance-Verpflichtungen damit verbunden sind. Wenn Sie rohe Kartendaten verarbeiten, ist die PCI-DSS Compliance obligatorisch. Wenn Ihr PSP die Tokenisierung übernimmt, können Sie die PCI-DSS Compliance möglicherweise ganz vermeiden.

Ihre Pre-Launch-Checkliste

Bevor Sie mit UCP live gehen, sollten Sie sicherstellen, dass Sie getestet haben:

Überprüfung von Signaturen

• Überprüfen Sie die Signaturen bei jeder eingehenden Anfrage/jedem eingehenden Webhook
• Ablehnung ungültiger, abgelaufener oder fehlerhafter Signaturen
• Ablehnen von Signaturen mit alg: "keine"
• Test mit einer gefälschten Signatur - er sollte fehlschlagen
• Test mit einer abgelaufenen Signatur - er sollte fehlschlagen

Validierung der Bindung

• Prüfen Sie, ob die Kassen-IDs zwischen Token und Zahlung übereinstimmen.
• Test mit einem Token von einer Kasse für eine andere - er sollte fehlschlagen
• Test mit abgelaufenen Token - er sollte fehlschlagen
• Prüfen Sie, ob sich die Details der Kasse (Artikel, Preise, Summen) nicht geändert haben.

Token-Ablauf

• Token laufen nach der dokumentierten Zeit ab (normalerweise 5-30 Minuten)
• Abgelaufene Token werden abgelehnt
• Testen Sie mit einem alten Token - er sollte fehlschlagen.

Konfiguration der Handler

• Überprüfen Sie die Zahlungsabwickler, bevor Sie sie akzeptieren.
• Prüfen Sie, ob die Konfiguration der Handler Ihren Erwartungen entspricht
• Test mit einem gefälschten Handler - er sollte fehlschlagen
• Test mit einer bösartigen Handler-Konfiguration - er sollte fehlschlagen

Aushandlung von Fähigkeiten

• Überprüfen Sie das Plattformprofil vor der Verarbeitung von Anfragen
• Fähigkeitskreuzung korrekt berechnen
• Ablehnung nicht unterstützter Operationen
• Angemessene Behandlung von Versionsabweichungen
• Testen Sie mit nicht unterstützten Fähigkeiten - sie sollten fehlschlagen.

Eingebetteter Checkout (falls verwendet)

• Sandbox-Einschränkungen verhindern ein Entkommen
• CSP-Direktiven werden erzwungen
• Host-App bestätigt vor der Freigabe von Zahlungsinformationen
• Testen Sie stille Zahlungsversuche - sie sollten fehlschlagen.
• Testen Sie Sandbox-Fluchtversuche - sie sollten fehlschlagen.

Autonome Agenten / AP2-Mandate (falls verwendet)

• Signaturen werden korrekt verifiziert
• Ungültige Signaturen werden zurückgewiesen
• Algorithmus-Verwechslungsangriffe werden abgewiesen
• Test mit manipuliertem Checkout - die Signaturprüfung sollte fehlschlagen
• Test mit abgelaufenen Schlüsseln - er sollte fehlschlagen (oder erfolgreich sein, wenn innerhalb der Schonfrist)

Die Quintessenz

UCP ist gut durchdacht, aber die Verantwortung für die Sicherheit liegt bei Ihnen.

Die gute Nachricht: Die meisten Sicherheitsprüfungen sind einfach zu handhaben.

Die schlechte Nachricht: Wenn Sie sie auslassen, sind Sie sowohl bösartigen Plattformen als auch bösartigen Benutzern ausgesetzt.

Haben Sie Fragen zu Ihrer spezifischen Implementierung? Gehen Sie diese Szenarien vor dem Start mit Ihrem Sicherheitsteam und einer dritten Partei wie Bureau Veritas Cybersecurity durch. Das wird Ihnen später Kopfschmerzen ersparen.