Paypal zählt auf keinen Fall zu den sichersten Plattformen des Netzes. Es ist definitiv möglich bei den meisten Download-Plattformen mit Paypal-Zahlungsmöglichkeit für einen Bruchteil des eigentlichen Kaufpreis und seine Downloads zu kommen. Bisweilen lassen sich sogar komplette Bezahlungsvorgänge simulieren.

Das Unternehmen gibt sich typisch amerikanisch aufgeblasen: Auf der Website sieht man, dass in vielen Sektoren was gemacht wird: für Händler, für Security, für eBay‘ler, für Privatmann, als Entwickler hat bekommt man massenhaft Downloads und Features geboten – noch nie war Bezahlen so einfach, und vor allem so unsicher.

Unsicher deswegen, da sich der Bezahlungs-Vorgang bei den meisten Online-Shops sehr einfach manipulieren lässt – nämlich indem man einfach den zu zahlenden Betrag ändert, oder den kompletten Bezahlvorgang einfach umgeht!

Die Implementierung der Bezahlung der Ware an sich ist nach Paypal-Dokumentation in wohl über 90% der Shops einfach schlampig implementiert. Das bringt in erster Linie Vorteile für den betrügerischen Kunden, und Nachteile für die Händler – allem voran Download Shops. Hier ist es möglich locker 1.000 Artikel in den Warenkorb zu legen, und dafür 0.01 ¢ zu bezahlen, oder die Bezahlung einfach komplett zu faken.

Implementierungen von Paypal

Professionelle Anwender

Für den professionellen Anwender stellt PayPal eine SOAP-API zur Verfügung. Hier kommuniziert der Shop des Händlers direkt mit PayPal, und ein Besuch der PayPal-Webseite wird nur zu Authentifizierung des PayPal Accounts des Nutzers benutzt.

Trotzdem gibt es hier keine einfachen Beispiele zur Implementierung der API: PayPal bietet zwar verschiedene SDKs an – allen voran Java und PHP – trotzdem findet man hier eher eine komplette Testsuite, aus der man dann seine eigene Implementierung herausziehen darf, statt ein einfach zu nutzendes Beispiel.

Und auch hier wird der Bezahlbetrag trotz sicherster Kommunikation über SOAP 1.2 SSL oder PayPal 3-token Authentification, später dem Shop per URL übergeben, und somit dem Nutzer oder Hacker offengelegt. Eine Prüfung des zu zahlenden Betrages findet im PHP-Beispiel des SDK nicht statt. Kein Wunder dass sowas auch übernommen wird.

Das der Wunsch nach einfachen SDKs oder Beispielen da ist können einigen Webseiten mit Developer und PayPalim Namen der Domain entnommen werden. Im PayPalEntwickler-Forum werden fleißig Sources ausgetauscht, die entweder gar nicht funktionieren, nur halb funktionieren oder spätestens beim nächsten Update der PayPal SOAP-Schnittstelle Gefahr laufen nicht mehr zu funktionieren.

Nachdem ich einige Klassen durchprobiert hatte, führte für mich schließlich kein Weg am PayPal-SDK vorbei, dass seinerseits auf PEAR aufbaut.

Semiprofessionale oder Private Anwender

Hier stellt PayPal Händlern einerseits die Möglichkeit vor, die komplett angebotenen Artikel in PayPal wirklich als Produkte zu integrieren und PayPal selbst als Warenkorb zu benutzen, andererseits gibt es die Möglichkeit PayPal per einfacher Einbindung als Formular in eine HTML-Seite PayPal den Empfänger der Zahlung, sowie den zu zahlenden Betrag zu übergeben (typischer Verkauf oder Spende).

Letztere Methode ist angreifbar, da hier Währungsbeträge über den Browser des Nutzers übergeben werden, während beim Warenkorb nur Produktnummer übergeben werden.

Im großen ganzen funktioniert dies nun so, dass der Webshop PayPal über den Browser des Nutzers seine Variablen (Zu zahlender Betrag, Empfänger, Return-URL bei erfoglreicher und abgebrochener Zahlung) im Klartext übergibt. Hier ist der erste Punkt an dem der Nutzer eingreifen kann.

Nehmen wir an ich manipuliere die Zahlung und will nur 0.01 ¢ zahlen. PayPal bekommt also vom „Shop“ mitgeteilt, dass der Kunde 0.01 ¢ zahlen will. Die Zahlung läuft bei PayPal ohne Probleme, und bei Abschluss der Zahlung leitet PayPalauf eine vorher vom Shop mitgeteilte Seite zurück – wieder per eingebundenem Formular. Dies ist meist eine URL mit einem vom Web-Shop generiertem Schlüssel für den Auftrag, so das der Web-Shop kapiert, dass eine Bezahlung für den Auftrag des Kunden erfolgt ist. Auch dies ist manipulierbar, z.B. kann ich so aus 0.01¢ wieder den vollen Betrag machen.

Bisweilen ließe sich durch die vom Web-Shop selbst übergebenen Variablen auch die komplette Bezahlung simulieren. Der Webshop bekäme hier bei schlampiger Implementierung – was im Übrigen Standard zu sein scheint – nichts mit.

Weiteres

Übernimmt man die Beispiele aus der PayPal-Dokumentation „Standard Integration“ findet sich dort kein Hinweis darauf, dass es vielleicht sinnvoll wäre die Zahlen gegenzuprüfen. Erst nachdem ich die Angreifbarkeit einiger Shops durchtestete fand ich nach etwa einer Stunde Dokumentationen wälzen, fünf Punkte, die dem Anwender einige Vorschläge machen:

1. Check that the payment_status is Completed.
   
2. If the payment_status is Completed, check the txn_id against the previous PayPal transaction you have processed to ensure it is not a duplicate.
   (Anm. id um nicht doppelte Transkationen durchzuführen)
3. After you have checked the payment_status and txn_id, make sure the receiver_email is an email address registered in your PayPal account.
   (Anm. läßt sich weiterhin faken!)
   
4. Check that the price, mc_gross, and currency, mc_currency, are correct for the item, item_name or item_number. (Anm. Tja, das sollte man eigentlich bei einer guten Implementierung prüfen; viele tun es wahrscheinlich nicht!)
   
5. Check the the shared secret returned to you is correct.
   (Anm. „ist mir zu kompliziert der Krypto-Kram“, wie der deutsche Max sagen würde)

So, und jetzt dürft ihr mal raten, in welchem dieser Dokumente das drinnen stand!

Kreditkarte, PCI Zertifkat und HMAC

Die Sparkasse nimmt es mit Sicherheit sehr ernst: Da dürfen die Web-Services gar nicht verwendet werden, wenn der Shop nicht über ein PCI Zertifkat verfügt, d.h. die sensiblen Kreditkarten-Daten auf dem Übertragungsweg nicht gesichert sind. Weiterhin ist ein SSL-Zertifikat ist da schon einmal die Voraussetzung für die Webseite, sowie ein intensiver Security-Check, dass auch alle Daten sicher sind und unerlaubte nicht gespeichert werden. VISA und MasterCard bzw. die Sparkasse schicken da für das PCI Zertifkat schon einmal einen Datenschutzbeauftragten in entsprechende Unternehmen.

Kann ein SSL-Zertifikat nicht angeboten werden, so gibt es von der Sparkasse einen Formular-Service, der über eine HTTPS Verbindung läuft, und so dem Kunden entsprechende Sicherheit gewährt. Um sicherzustellen, dass auf der Sparkassen-Seite auch genau die Variablen verwendet werden, die vom Shop kommen – also u.a. der zu zahlende Betrag – werden die Variablen über den HMAC gehashed, d.h. es wird sichergestellt, dass auch über eine unsichere Verbindung wie HTTP, die Variablen sicher übertragen werden.

Beides bietet Paypal natürlich nicht an! Soweit ich es sehe, gibt es bei PayPal anscheinend keine Einschränkungen auch Kreditkartenzahlungen über unsichere Verbindungen anzubieten.

„Verbrennt die Hexe!“

Erst einmal ist die Schuld eindeutig auf Seiten der Unwissenheit der Anwender oder besser gesagt Händler zu sehen. Die meisten Menschen sind einfach noch nicht reif für diese neue Welt. Sorry, aber so ist es!

Andererseits ist sehe ich auch Versagen seitens PayPal, die schlampig gearbeitet haben. Bei den lieben Amerikanern zählt nun einmal leider eher Masse statt Klasse, und die Transparenz und somit Sicherheit bleiben da auf der Strecke: Just keep it simple!

Nun, was macht wohl so ein Unternehmen wie PayPal im Falle des Missbraches? Es löscht wohl einfach den PayPal-Account, und somit wäre das Problem erstmal gelöst. Willkommen im Mittelalter!

Trotzdem hat der Händler noch seine Probleme: Dieser wundert warum Nachforschungen über bestimmte IPs nur Länder wie Thailand oder Korea zu Tage fördern, und warum gerade diese Koreaner mit 100 GB Downloads seine Webseite so toll finden. Andererseits kann er es ja mal mit Klagen gegen Betrug versuchen – unsere Richter kennen ja wunderbar gut mit dem Thema Internet aus…