Da ein Leser in einer Email eine Frage zu "Hacking im Web" gestellt hat, deren Beantwortung auch für andere Leser des Buches spannend sein kann, schreibe ich diesen Artikel im Blog.

Konkret hat der Leser nach dem im Kapitel 1.5 "Das (Kern-)Problem" gezeigten Beispiel gefragt und hat sich erkundigt, ob es jemals funktioniert hat oder per Bildbearbeitung erstellt wurde.

Für alle die das Buch zum Thema Webhacking noch nicht gelesen haben oder sich nicht erinnern, worum es an dieser Stelle geht: Hier ein kurzer Textausschnitt mit dem angesprochenen Beispiel.

Buchauszug: 1.5 "Das (Kern-)Problem"

Gleich zu Anfang möchte ich auf ein mögliches Kernproblem zu sprechen kommen, wenn es um die Sicherheit von Webapplikationen geht: Viele Menschen (auch erfahrene Entwickler) denken, dass Applikationen etwas falsch machen oder die Sicherheit aufgrund der Applikation selbst nicht gegeben ist. Das ist jedoch weit gefehlt, denn Applikationen (und Computer generell) tun immer nur das, wozu sie angewiesen wurden. Sie folgen dabei streng ihrem Ablauf und funktionieren, rein logisch betrachtet, wie sie sollen. Nur wenn ein Fehler in der Verarbeitung einer Anweisung vorliegt, kommt es auch zu einem Fehler in der Applikation. Und Anweisungen kommen dabei fast ausschließlich von dem Benutzer einer Anwendung. Wir werden in diesem Buch lernen, dass die meisten Fehler eigentlich nur zu Sicherheitslücken werden, wenn Applikationen von den Entwicklern nicht klar angewiesen werden, wie sie zu funktionieren haben.

Die hier abgebildete Google-Suche zeigt mustergültig, wie schnell es zwischen dem Nutzer und einer Anwendung zu Missverständnissen kommen kann. Es bleibt unklar, ob wir »in Paderborn essen gehen« möchten oder wir von »Paderborn bis nach Essen gehen« möchten. Was in diesem Beispiel noch harmlos ist und ein Fehler ohne große Auswirkung, kann bei sensiblen Eingaben in komplexen Applikationen schnell zu einem Sicherheitsrisiko werden. Angreifer machen sich oftmals genau eine solche Systematik zunutze. Die Applikation kann dafür nichts, vielmehr sind es Entwickler und Programmierer, die nicht alle möglichen Fälle bedacht oder aufgefangen haben. Welche Folgen das genau haben kann und wie es uns gelingt, bestmöglichsten Schutz vor solchen "Missverständnissen" zu erhalten, wollen wir gemeinsam in diesem Buch genauer untersuchen.

Soweit zunächst der Ausschnitt (übrigens lässt sich ein Teil des Hacking-Buches - auch der hier angeführte Ausschnitt - in der Leseprobe betrachten). Prüfen wir also einmal nach, was der Absender der oben genannten Email meinte und geben die Anfrage "paderborn essen gehen" in Google ein.

Das Ergebnis erstaunt, die Suche fällt anders aus als im Buch abgebildete. Das liegt nicht daran, dass ich für das Buch ein Bild erstellt habe (im Buch sind alle Beispiele mehrfach geprüft und echt!) - sondern da Google die Eingabe mittlerweile anders verarbeitet. Warum das der Fall ist, kann ich Ihnen leider nicht beantworten - allerdings ist zu vermuten, dass Google (als Entwickler der Applikation) nun eine korrektere Interpretation der Eingabe des Benutzers vornehmen: Die meisten Nutzer wollen wohl "in Paderborn essen gehen" und nicht "von Paderborn nach Essen gehen". Es sei denn, sie wollen einmal 27 Stunden am Stück über die B1 laufen - was ich persönlich für die meisten allerdings eher für unwahrscheinlich halte :) Was meinen Sie?

Nachdem ich festgestellt habe, dass die Eingabe von Google mittlerweile anders behandelt wird war ich etwas enttäuscht - mir war zwar klar, dass gewisse Dinge (in Hacking-Fachbüchern) eine geringe Halbwertszeit haben, mit einer so schnellen habe ich allerdings nicht gerechnet. Aber natürlich gibt man so schnell nicht auf (wichtige Eigenschaft eines Hackers) ... deshalb habe ich es einfach mit einem anderen Städtenamen versucht:

Und voila, es funktioniert beispielsweise noch mit "berlin essen gehen" (Stand 29.08.2016) - fragt sich nur wie lange noch :) Geht es auch mit Ihrer Stadt?

Falls Sie eine ähnliche Google-Anfrage, wie die obrige kennen, können Sie sich natürlich auch gern bei mir melden - meine Erfahrung zeigt mir, dass sich an Hand solcher Beispiele Schwachstellen deutlich schneller beschreiben lassen.

Sollten Sie, wie der Leser, der sich mit der Anfrage die diesem Artikel zu Grunde liegt, auch etwas fragen wollen oder eine Anregung zum Buch haben, können Sie sich sehr gern an mich wenden. Die Kontaktdaten lassen sich hier entnehmen.

Ich freue mich über Nachricht von Ihnen! Bleiben Sie sicher!

Tim Philipp Schäfers

PS: Übrigens, die in dem Beispiel gezeigte doppelte Semantik liegt insbesondere den Angriffsvektoren: SQL-Injection, Cross-Site-Scripting und NULL-Byte Injection zu Grund - in Kürze werde ich ein "Verzeichnis zu bekannten Schwachstellen im Web" auf diesem Blog anlegen - in der Sie die einzelnen Schwachstellen kennenlernnen können.