Autor: Carsten 3. Juni 2015 0 Kommentare

Im Dezember 2008 hatte ich unter SQL Injection Attack mit Hilfe der Stadt darüber berichtet, dass ich mit unserem Straßennamen “ Auf’m Diek “ bei einem Internethändler auf nicht unerhebliche Probleme gestoßen bin.

Für diejenigen, die nicht viel mit SQL am Hut haben, will ich mal kurz erläutern, was damals passiert ist: Bei SQL, das ist eine Datenbanksprache, die auf den meisten Webseiten verwendet wird, werden Texte in Hochkommatas eingeschlossen, um zu kennzeichnen, wo der Text anfängt und wo er endet. Außerhalb der Hochkommatas stehen Befehle, was die Datenbank machen soll. Ein typischer Befehl sähe also so aus:

SELECT address FROM customer WHERE name='Carsten';

Soll nun der eigentliche Text selbst ein Hochkomma haben, so muss man es speziell kenntlich machen, der Experte sagt „escapen“. Dies erfolgt bei SQL durch einen vorangestellten Backslash:

SELECT address FROM customer WHERE name='Carsten\'s Name';

Macht man das nicht, passieren mehr oder minder lustige Dinge: Die Datenbank kann nicht mehr unterscheiden, wo der Text endet und der nachfolgende Befehl endet. Randall Munroe von XKCD hat die möglichen Effekte in einem Comic sehr anschaulich beschrieben:

Seitdem meinem vorhergehenden Posting sind fast 7 Jahre vergangen. SQL Injection Angriffe sind inzwischen selbst in der Breiten Öffentlichkeit angekommen und für jeden seriösen Entwickler ist es inzwischen Standard, seine Anwendung auf solche Schwachstellen zu überprüfen. Darüber hinaus sorgt auch jede halbwegs aktuelle Datenbankabstraktionsschicht inzwischen dafür, dass soetwas nicht mehr passieren kann. Jede…..? Fast!

Eine Begegnung der dritten Art erlebte ich die Tage bei Pollin, als ich versuchte, über deren Webseite ein paar Elektronikkomponenten zu bestellen. Bestellung abgeschickt, wohl weislich ohne Apostroph in unserem Straßennamen. Bestellbestätigung per Mail bekommen. Nur leider kein Paket. Eine Rückfrage an die Mailadresse offenbarte:


Guten Tag, Herr Schumann,

vielen Dank für Ihre E-Mail.
Leider liegt uns kein Auftrag mit der Bestellnummer ###### von Ihnen vor.
Wir bitten Sie die Bestellung erneut zu tätigen.


An dieser Stelle glaubte ich noch an ein ganz normales EDV-Problem. Schließlich haben selbst die größten Systeme auch einmal etwas Schluckauf. Gesagt getan, Bestellung erneut eingegeben Bestellbestätigung per Mail bekommen und per Mail direkt nachgefragt, ob die Bestellung auch im System angekommen ist. Die darauffolgende Antwort ließ bei mir jedoch alle Alarmglocken schrillen:


Guten Tag, Herr Schuhmann,

vielen Dank für Ihre E-Mail.
Leider haben wir keinen Auftrag erhalten.
Sie müssten das Apostroph aus der Straße entfernen und dann bestellen.
Solang das Apostroph drin ist, kommt der Auftrag bei uns nicht an.


OK. Fassen wir zusammen: Ich habe eine Lieferadresse ohne Apostroph im Straßennamen eingegeben und das System verschluckt sich wegen einem Apostroph. Wie kann das sein….?

Offensichtlich führt Pollin einen automatisierten Abgleich mit den Datenbanken eines Bonitätsdienstleisters (z.B. Schufa) durch, um sich gegen Zahlungsausfälle abzusichern. In dem Zuge wird dann auch automatisch die Adresse „korrigiert“, was in einem nachgelagerten System zu einem Problem führt und die Datenübergabeschnittstelle sprengt. Mit ein wenig Kreativität könnte man an dieser Stelle mit Sicherheit ziemliches Unheil einrichten, ich sage nur „Little Bobby Tables“.

Und was lernt der interessierte Programmierer daraus?

1. Datenbankeingaben überprüfen (oder ein vernünftiges Framework verwenden)
2. Selbst programmierte Schnittstellen vernünftig und ausgiebig testen
3. Daten nicht blind von anderen Dienstleistern übernehmen
4. Gelegentlich mal einen Blick in die Server-Logs werfen. Bevor solche Lücken für Angriffe ausgenutzt werden sieht man meist die Fehlermeldungen durch unbeabsichtigte Fälle, wo die Lücke auch schon den normalen Programmfluss stört.

Bleibt nur zu hoffen, dass Pollin die gleichen Schlüsse daraus zieht und die Sicherheitslücke in Größe eines Scheunentors zeitnah zumacht. Die nächste Bestellung kommt bestimmt…