SQL Injection Attack mit Hilfe der Stadt

Umzüge bringen ja so einiges mit sich. Unter anderem auch meistens eine neue Adresse. Bei der Planung des Wohngebiets, in das wir nun gezogen sind, hat die Stadt Dorsten jedoch außerordentliche Kreativität an den Tag gelegt und gezeigt, dass Straßennamen nicht nur aus Buchstaben bestehen müssen.

Unsere Straße hat in dieser kreativen Phase den Namen Auf’m Diek bekommen und ja, das mit dem Apostroph ist die offizielle Schreibweise.

Für die ersten lustigen Effekte sorgte der Name bereits, als wir unsere DSL-Leitung bei Versatel bestellen wollten. Dort gab es nämlich ganze 5 Straßen, die in die Endauswahl kamen: Aufm Diek, Auf dem Diek, Auf'm Diek, Auf´m Diek sowie Auf`m Diek. Wir haben uns einfach mal für eine beliebige Variante entschieden und es hat auf Anhieb funktioniert.

Nicht so viel Glück hatten wir gestern, als wir im Internet etwas bestellen wollten. Produkt ausgewählt, ab zur Kasse, Kundenkonto angelegt, Versandadresse eingegeben und dann das:

1064 – You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
‚m Diek‘, ‚Dorsten‘, ‚46284‘, 0)‘ at line 2
INSERT INTO customers_credit_reform (score, customers_id, address_valid,
address_valid_code, address_known, address_street_no, address_street_name,
address_town, address_postcode, credit_error) VALUES (42, 91756,
“, ’03‘, ‚0‘, ’19‘, ‚Auf’m Diek‘, ‚Dorsten‘, ‚46284‘, 0)
[XT SQL Error]

BugEine solche Meldung lässt das Herz jedes Softwareentwicklers höher schlagen.

Für diejenigen, die nicht viel mit SQL am Hut haben, will ich mal kurz erläutern, was hier passiert ist: Bei SQL, das ist eine Datenbanksprache, 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. In der oberen Fehlermeldung soll beispielsweise in die Felder core, customers_id, address_valid, … , credit_error der Tabelle customers_credit_reform etwas eingefügt werden, und zwar die Werte (VALUES) die dahinter stehen. Zahlenfelder haben keine Hochkommatas (z.B. 00963) während Textfelder mit Hochkommatas eingeschlossen sind (z.B. ‚Dorsten‘).

Wenn man sich nun die Anweisung mal genau anschaut, dann fällt auf, dass bei ‚Auf’m Diek‘ irgendwie ein Hochkomma zu viel ist. Die Datenbank interpretiert dies so, dass der Text 'Auf' lautet und m Diek als SQL-Befehl interpretiert wird, der natürlich inkorrekt ist, was die oben gezeigte Fehlermeldung proviziert.

Mit ein bischen SQL-Wissen und aufgestautem Frust (weil z.B. die Bestellung nicht klappt) könnte jemand sich auch folgende Adresse ausdenken: 'irgendwas','','',9);DROP DATABASE;--'. Das resultierende SQL-Kommando sähe dann so aus:

INSERT INTO customers_credit_reform (score, customers_id, address_valid,
address_valid_code, address_known, address_street_no, address_street_name,
address_town, address_postcode, credit_error) VALUES (42, 91756,
“, ’03‘, ‚0‘, ’19‘, ‚irgendwas‘,“,“,9);DROP DATABASE;–‚, ‚Dorsten‘, ‚46284‘, 0)

schredderFür nicht-SQLler übersetzt und gekürzt: Füge irgendwas in die Tabelle customers_credit_reform ein und lösche danach die gesamte Datenbank. Alles nach dem — wird als Kommentar interpretiert und ignoriert. Der Shop-Betreiber wird sich freuen, wenn seine gesamten Daten weg sind.

Normalerweise würde man Hochkommata in Textfeldern einen Backslash voranstellen ' um sie zu „escapen“. Offensichtlich hat das der Programmierer dieses Webshops jedoch vergessen, obwohl PHP und andere Programmiersprachen hierfür extra Befehle haben und die meisten Datenbankabstraktionsschichten das schon automatisch machen. Tragisch sag ich nur.

Aber zurück zur Bestellung. Um das Problem zu umgehen, hab ich meine Adresse zu Aufm Diek korrigiert. Der Postbote findet das auch so. Aber auch hier hat mich der Webshop übertölpelt.

1064 – You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
‚m Diek‘, ‚Dorsten‘, ‚46284‘, 0)‘ at line 2
INSERT INTO customers_credit_reform (score, customers_id, address_valid,
address_valid_code, address_known, address_street_no, address_street_name,
address_town, address_postcode, credit_error) VALUES (00963, 91756,
‚Korrigierte Eingabeadresse wird ausgegeben‘, ’03‘, ‚0‘, ’19‘, ‚Auf’m
Diek‘, ‚Dorsten‘, ‚46284‘, 0)
[XT SQL Error]

Ich sag nur: Korrigierte Eingabeadresse wird ausgegeben.

Gegen soviel geballte Intelligenz des Webshops komm auch ich nicht an und hab mich mal entschlossen, das ganze per E-Mail zu bestellen. Mal sehen, ob der Webshop die Bestellung annimmt …

1 Kommentar

  1. Pingback: SQL Injection Attack mit Hilfe der Stadt, Teil 2 | Einmal 42 und zurück

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert