Grundlage: Sichere Integration von Online-Bezahldienstleistern

Egal, ob es sich bei der Verkaufsplattform um eine Webseite (wie bei einem Onlineshop) oder um eine spezielle Benutzersoftware (wie bei manchen Print­-on­-Demand-Diensten) handelt, existieren zu Beginn des Bezahlprozesses zwei relevante Datenobjekte: der Warenkorb mit seinem Gesamtpreis und die Kundeninformationen wie Name und Adresse. Die einfachste Lösung einer Vielzahl von Zahlungsanbietern besteht aus gehosteten Webseiten, die diese Daten übergeben bekommen und weitere zahlungsrelevante Informationen wie Kartennummer und einen etwaigen Sicherheitscode abfragen. Nach dem Bezahlprozess wird einserseits der Kunde zurück auf die Webseite des Händlers geleitet und andererseits die Verkaufsplattform vom Zahlungsanbieter automatisiert über den Erfolg und Status der Bezahlung informiert.

Schiedsrichter

Um Sicherheit und Datenschutz bei Online­-Bezahlungen zu erreichen, wurde von marktführenden Kreditkartenorganisationen der Sicherheitsstandard PCI DSS entwickelt. Er schreibt vor, dass Unternehmen, die Kreditkartendaten speichern, verarbeiten oder weiterleiten bestimmte Sicherheitsanforderungen erfüllen und Sicherheitsüberprüfungen vornehmen bzw. vornehmen lassen. Eine Zertifizierung nach PCI wird häufig als Gütesiegel im Bereich des E­Commerce verwendet, obwohl Sicherheitsexperten die Messlatte als viel zu tief angelegt erscheint. Tatsächlich wurde beispielsweise Anfang letzten Jahres ein US­Lebensmittelhändler zertifiziert, obwohl zu diesem Zeitpunkt bereits zwei Monate lang unbemerkt Malware Kreditkartendaten sammelte. Verwendet ein Händler die gehosteten Webseiten eines Bezahlanbieters, ist er von den PCI­Regularien nicht unmittelbar betroffen: Speicherung, Verarbeitung und Weiterleitung von Kreditkartendaten finden ausschließlich auf den Systemen des Bezahlanbieters statt.

Datenaustausch

Bei der beschriebenen Integrationsart erfolgt die Übertragung der Bestell­ und Kundeninformationen an den Zahlungsanbieter typischerweise in Form eines HTTP GET­ oder POST­Requests, so dass grundsätzlich ein einfaches HTML­Formular ausreichend ist, um den Bezahlprozess zu initiieren. Damit jedoch die Daten an dieser Stelle nicht manipuliert werden können (etwa um den Gesamtbetrag zu ändern), werden sie zusätzlich kryptografisch gesichert. <% @page import =" java .io. ByteArrayOutputStream " %> <% @page import =" java . math . BigDecimal " %> <% @page import = " org . bouncycastle . crypto . digests . SHA1Digest " %> <% @page import = " org . bouncycastle . util . encoders . HexEncoder " %> <% @page import ="de. ndurner . Order " %> <% Order order = ( Order ) session . getAttribute (" Order "); String amount = order . getTotal (). multiply ( new BigDecimal (100.0)). toBigInteger (). toString (); String account = application . getInitParameter ( " pspAccount "); byte orderData [] = ( order . getID () + amount + order . getCurrency () + account + application . getInitParameter (" pspMacSecret " )). getBytes (); SHA1Digest md = new SHA1Digest (); md. update ( orderData , 0, orderData . length ); byte mac [] = new byte [md. getByteLength ()]; md. doFinal (mac , 0); 1 ByteArrayOutputStream shaSign = new ByteArrayOutputStream (); ( new HexEncoder ()). encode (mac , 0, md. getDigestSize (), shaSign ); %> <html > <body > <form action =" <%= application . getInitParameter (" pspUrl ") %>" method =" post "> <input name =" PSPID " value =" <%= account %>" type =" hidden " /> <input name =" orderID " value =" <%= order . getID () %>" type =" hidden " /> <input name =" amount " value =" <%= amount %>" type =" hidden " /> <input name =" currency " value = " <%= order . getCurrency () %>" type =" hidden " /> <input name =" language " value = " <%= order . getLanguage () %>" type =" hidden " /> <input name =" SHASign " value = " <%= shaSign . toString (). toUpperCase () %>" type =" hidden " /> <input type =" submit " value =" Weiter zur Bezahlung " /> </form > </body > </html >

Das Listing zeigt ein minimales JSP­-Formular für den Bezahldienstleister Ogone  . Neben den Auftragsinformationen werden auch der Name des Händleraccounts ("PSPID") und eine kryptografische Prüfsumme ("SHASign") übergeben. Letztere wird aus der Auftragsnummer, dem Auftragswert (multipliziert mit 100, um Nachkommastellen zu vermeiden), der Währung und einem beim Bezahlanbieter hinterlegten geheimen Schlüssel errechnet. Zusätzlich zu den gezeigten Pflichtparametern können noch weitere Informationen über den Kunden (Name, E­Mail, Adresse, ...) und auch Informationen zum Aussehen der Bezahlseiten übergeben werden. Sind die URLs für die Übermittlung des Zahlungsstatus und der Weiterleitung des Kunden nicht fest (und damit einmalig über das Administrationsinterface einstellbar), können auch diese in separaten Feldern übergeben werden. Die Schnittstellen anderer Anbieter unterscheiden sich hauptsächlich in den gewählten Feldnamen und dem verwendeten Prüfsummen­ bzw. Chiffrieralgorithmus.

Halbe Sicherheit

Wie eingangs erwähnt, wird die Übergabe der Bezahlinformationen und die Rückgabe des Bezahlstatuses kryptografisch gesichert, so dass keine weitreichenden Manipulationen möglich sind. Dazu werden bei Ogone die zu sichernden Daten zu einem String verkettet, diesem ein geheimer Schlüssel hinten angefügt und das Ergebnis gehashed. Zwar gilt dieses Verfahren beim Einsatz von auf dem Merkle-Damgård­-Prinzip aufbauenden Hashfunktionen (wie in diesem Fall SHA­1) als unsicher, jedoch spielt dies durch die kleine Menge an zu hashenden Daten (weniger als 64 Bytes) und den bis jetzt nicht praktisch durchführbaren Angriffen auf die Kompressionsfunktion von SHA­1 aktuell keine bedeutende Rolle.

Weit ernster ist die Lage beim Bezahldienstleister Worldpay  . Hier wird (als optionales Sicherheitsfeature) der geheime Schlüssel vor die verketteten Auftragsdaten gestellt und anschließend mit dem SHA­Vorgänger MD5 gehashed. Dieser Algorithmus ist anfällig für verschiedene Angriffe, insbesondere der differentiellen Analyse, mit der bereits die Fälschung von PDF­-Dokumenten, Windows­-Programmen und einem SSL-­Zertifikat gelungen ist. Eine sehr änliche Verwendung von MD5 mit geheimem Präfix hat in jüngster Vergangenheit darüber hinaus eine Sicherheitslücke in die API des Onlinebilderdienstes Flickr   gerissen.

Computop hat mit der symmetrischen Verschlüsselung aller Auftragsinformationen einen anderen Ansatz gewählt. Während der verwendete Chiffrieralgorithmus Blowfish bislang als ungebrochen gilt, wurde bereits vor 30 Jahren der zum Einsatz kommende ECB­Modus für solche Anwendungsfälle als ungeeignet beschrieben: anders als bei anderen Modi ist bei gleichem Schlüssel das Chiffrat eines einzelnen Datenblocks (im Falle von Blowfish 64 Bit) unabhängig von dessen Position im Klartext immer gleich. Dadurch können einerseits unverschlüsselte Datenblöcke mit verschlüsselten Datenblöcken direkt in Zusammenhang gebracht werden, und andererseits Datenblöcke im Chiffrat ohne Kenntnis des Schlüssels ausgetauscht und angehängt werden.

Da die Parameternamen im Verhältnis zur Blocklänge des Chiffrierers lang sind, sie in der Referenzimplementierung der Schnittstelle immer in einer festen Reihenfolge übergeben werden und die Dateninhalte von einem Angreifer beeinflusst werden können (z.B. durch Variationen im Namensfeld), ist es insbesondere bei Kenntnis der API möglich, Bezahlinformationen zu fälschen oder im Falle ungesicherter Vorgängerseiten abzuhören. Die Abbildungen 2 und 3 zeigen vereinfacht die ersten Blöcke von Bestelldaten, die nur im Preis abweichen.

Eine spezifische Schwäche der ASP­-Implementierung der Computop-­Schnittstelle ist die Tatsache, dass die zu installierende DLL bei der Überprüfung ihrer Parameter nachlässig ist und infolgedessen Speicherverletzungen provoziert werden können.

Abhärtung

Im Fall von Computop   können Fälschungen erschwert werden, indem die Reihenfolge der Parameter wie in Abbildung 4 für jeden Bezahlvorgang zufällig festgelegt wird und wie in Abbildung 5 gezeigt bedeutungslose Füllparameter mit zufälliger Länge eingestreut werden, welche die Nutzdaten zum einen an unterschiedliche Positionen innerhalb eines Blockes schieben und zum anderen sich im Chiffrat mit den Nutzdaten vermengen. Bei der Auswertung des Bezahlstatuses sollten aufgrund der Manipulationsmöglichkeiten nur die IP­Subnetze von Computop als Absender zugelassen und bei der Verwendung des txmsCrypto­Moduls auf jeden Fall die Längen(angaben) der Parameter geprüft werden.

Schwache Verschlüsselungsalgorithmen und Hashsignaturen, die nur aufgrund mangelnder Kollisionsresistenz problematisch sind, können durch häufige Schlüsselwechsel und sorgsame Schlüsselwahl (z.B. im Hinblick auf Entropie und Länge) in ihrer Wirksamkeit verbessert werden. Darüberhinaus können über frei belegbare Parameter der Bezahlschnittstellen zusätzliche Signaturen übertragen werden, die mit einem als Industriestandard geltenden Verfahren wie HMAC in Verbindung mit einem sicheren Hashalgorithmus (z.B. SHA­2) oder einem modernen Signaturverfahren wie UMAC oder Poly1305 in Verbindung mit einem sicheren Verschlüsselungsalgorithmus wie AES generiert wurden. Da diese Parameter von den Bezahldienstleistern nicht beachtet werden, können sie allerdings nur von der Verkaufsplatform selbst bei Callback­Aufrufen geprüft werden.

Eine Variante, die sich nicht auf die Sicherheit kryptografischer Funktionen verlassen muss besteht wie in Abbildung 6 skizziert darin, serverseitig die Anfrage an die erste Bezahlseite zu stellen und das Ergebnis dem Kunden auszuliefern. Dadurch werden - ausgehend von einer sicheren Umsetzung der Bezahlseiten selbst - die schützenswerten Informationen in keinster Weise dem Kunden oder etwaigen Mittelsmännern enthüllt und können somit auch nicht ausgelesen oder manipuliert werden. Da in diesem umgeleiteten Datenfluss z.B. keine Kreditkartendaten enthalten sind, ist dieses Verfahren im Hinblick auf die Anforderungen von PCI DSS unbedenklich.

Eine weitere Möglichkeit, Betrug vorzubeugen ist eine nachgelagerte Abbuchung (s. Abbildung 1). Dabei wird nach der sogenannten "Autorisierung" der Transaktion durch den Kunden der Gesamtbetrag lediglich reserviert und z.B. erst beim Versand der Ware tatsächlich abgebucht ("Capture" oder "Settlement"). Da Abbuchungen den reservierten Betrag niemals übersteigen dürfen, würde ein etwaiger Betrug insbesondere bei automatisierten Abbuchungsprozessen auffallen.

Gesundes Misstrauen

Sicherheitsbewusste Kunden von Einkaufswelten im Internet können sich aufgrund der Vielzahl von möglichen Sicherheitslücken nur sehr schwer davon überzeugen, dass ihre Daten nicht bereits bei der Übermittlung vom heimischen PC aus in dunkle Kanäle fließen. Bestmögliche Sicherung des Transportwegs wird erreicht, wenn alle Seiten des Shops per HTTPS zur Verfügung gestellt werden. Sind nur Teile SSL­-gesichert, muss zumindest darauf geachten werden, dass Formulare, auf denen persönliche Informationen eingegeben werden bereits verschlüsselt abgerufen wurden und das SSL-­Zertifikat zum Webshop gehört. Im Falle von gehosteten Bezahlseiten wird für diese das SSL­-Zertifikat des Bezahlanbieters verwendet, insofern sollte hier bereits die aufrufende Seite verschlüsselt sein, um Manipulationen oder Ausspähung der per Parameter übergebenen Informationen durch Dritte auszuschließen.

Darüber hinaus ist es für den Shopbetreiber bei aktivierten Cookies besser möglich, auch bei nur teilweisem SSL-­Schutz einen sicheren Sitzungsbezug herzustellen. Während ein Kunde nicht auf einfachem Wege den korrekten Einsatz sogenannter "Secure Cookies" überprüfen kann, sollten Cookies trotzdem vorsichtshalber vor dem Einkauf aktiviert und nach dem Einkauf wieder gelöscht werden. Wie auch beim Online­-Banking empfiehlt es sich, danach den Browser­Cache zu leeren, den Browser zu schließen und nicht nach erfolgter Anmeldung an den Shop auf anderen Seiten parallel zu surfen.

Möglichst nahtlose Integration anstreben

Wirkungslose Sicherungsmechanismen von eigentlich PCI­zertifizierten E­Commerce­-Systemen zeigen, dass Händler, Bezahldienstleister, Integrationspartner und evtl. eingebundene Sicherheitsberater Hand in Hand arbeiten müssen, soll die Sicherheit von Kunden und Händlern gleichermaßen gewährleistet werden. Auf Händlerseite muss angestrebt werden, dass die Integration möglichst nahtlos vorgenommen wird und am besten mehrere unabhängige Prüfmechanismen zum Einsatz kommen. Bezahldienstleister sollen aktuellste und gleichzeitig anerkannte Mechanismen anwenden und sich insbesondere der in der Fachwelt anhaltenden Diskussion um Algorithmen-Agilität öffnen.

---

iBusiness-Autor Nils Durner ist Softwareentwickler bei dmc digital media center   . Seine Interessensgebiete beinhalten Computersicherheit, Datenbanken und P2P Networking.