Jede*r Entwickler*in muss auch Hacker*in sein

Hast du heute schon etwas kaputt gemacht? 

Als Entwickler*In haben wir in der Regel die Aufgabe, etwas Neues zu bauen, Business-Logik in Code zu gießen und neue Features live zu bekommen. Daher wundert es nicht, dass viele von uns ein Wie-baue-ich-Mindset haben, und kein Wie-mache-ich-kaputt. Mit „Kaputt machen“ ist natürlich nicht gemeint, Schaden anzurichten. Es geht vielmehr darum zu verstehen, welchen Gefahren eine Software ausgesetzt ist. Damit wir robustere und sicherere Anwendungen bauen können. 

Cybersecurity ist ein weites Feld. Um wieviel Sicherheit sollte ich mich als Developer*In kümmern? Durch die zunehmende Digitalisierung und immer schnellere Release-Zyklen steigt unsere Verantwortung. Wir müssen uns nicht nur im Detail auskennen, sondern auch verstehen, wie sich das aktuelle Feature in das große Ganze einbindet. Und somit kommt wir nicht umher, uns intensiv mit dem Thema Security auseinanderzusetzen. 

Erfreulich ist, dass immer mehr Entwickler*Innen sich ihrer Verantwortung bewusst sind. Die Top 10 des Open Web Application Security Project OWASP und ähnliche Awareness-Dokumente sind gängige Begriffe. Frage ich aber Entwickler*Innen, ob sie die Angriffsmöglichkeiten schon mal ausprobiert haben, kommt häufig nur betroffenes Schweigen. 

Daher stellt sich mir die Frage, wieso nicht mehr Entwickler*Innen auch mal hacken? Wir haben die besten Voraussetzungen: gute Programmierkenntnisse, wir verstehen IT-Systeme und -Landschaften, sind es gewohnt, abstrakt und komplex zu denken und müssen auch mal kreative Lösungen finden. Liegt es an Hollywood, das uns ein sehr unrealistisches Bild vom Hacking gibt? Animierte, singende Viren gibt es echt nur im Fernsehen. Oder fehlt uns einfach nur ein kleiner Schubs, ein erster Schritt? Eine Lücke nachzustellen ist nicht schwer, die OWASP Top 10 sollten genügend Ideen geben. 

Warum also nicht einfach mal machen? Hier ein paar Hacks, die einfach auszuprobieren sind und mit wenig Aufwand das eine oder andere AHA! Erlebnis schaffen. 

Injection 

Der Klassiker ist die Injection, die es schon lange und leider immer noch gibt: Sie tritt bevorzugt dann auf, wenn eine Software ein Statement für einen anderen Interpreter erstellt und dabei Daten und Befehle vermischt werden. Das lässt sich einfach ausprobieren, ein LAMP Stack (Linux, Apache, MySQL und PHP) ist schnell aufgesetzt, Google hilft. 

In einem einfachen PHP Script bauen wir unvorsichtig und ohne Prüfung ein SQL Query per String zusammen: 

// Reading the input AS IS, without any sanitization or validation
$uid = $_GET[‘id’];
// Creating a SQL Select Statement via String concatenation, using the unchecked id.
$query = „SELECT * FROM users WHERE id = “ . $uid;

Wenn in dem Parameter ID nur ein Wert steht, funktioniert die Abfrage wie erwartet. 

http://localhost/user.php?id=1

Gibt man nun in der ID jedoch noch zusätzlich SQL-Befehle mit ein, lässt sich das Statement so ändern, dass es ggf. etwas macht, was in der Entwicklung nie vorgesehen war: 

http://localhost/user.php?id=1 AND 2=3 

Das angehängte “ AND 2=3″ sorgt zum Beispiel dafür, dass die Bedingung nie erfüllt sein kann, denn egal ob es die ID 1 gibt oder nicht, 2 ist niemals gleich 3. Wenn also nun kein User mehr gefunden wird, habe ich schon bestätigt, dass die Anwendung anfällig für SQL Injection ist.

Wenn man erstmal eine Lücke gefunden hat, kann man nun eigene Statements einschmuggeln und damit je nach Berechtigung auch Daten verändern und löschen. 

Eine umfangreiche und stetig aktualisierte Liste von Schutzmaßnahmen bietet zum Beispiel das SQL Injection Prevention Cheat Sheet von OWASP.

Massenabfragen 

Manche Anwendungen geben mehr über sich preis, als sie möchten. Zwar sind bestimmte Endpunkte nicht verlinkt, mit ein wenig Raten und Geduld lassen sie sich aber trotzdem finden, insbesondere wenn sie Standard-Namenskonventionen folgen. Gibt es etwa ein API Docs oder eine Swagger.json, also die technische Beschreibung aller Schnittstellen? Wurde eventuell das gesamte .git-Verzeichnis hochgeladen? Verrät etwa die robots.txt-Datei, welche URLs eigentlich geheim sein sollen? Manuell wird das schnell mühsam, aber mit einem Script oder einem API Tool wie Postman lässt sich der Prozess einfach optimieren. Und alles, was vom Normalverhalten abweicht, lohnt sich zu inspizieren. Wenn also eine Anfrage auf /tmp ein „404 Not Found“ zurück liefert, aber eine Anfrage auf /logs ein 401 oder gar 200 ergibt, wird es interessant. Listen mit typischen Verzeichnissen, Dateien oder gängigen Anwendungen wie z.B. phpMyAdmin lassen sich googeln. 

Postman eignet sich perfekt, um dieses Szenario einmal auszuprobieren. Da sich so gut wie überall Variablen verwenden lassen, können wir eine Collection mit dem nötigen Request erstellen, und diese dem Runner übergeben. Dort muss nur noch die Liste geladen werden, und Postman führt alles Requests brav für uns aus.

Wenn wir schon beim Skripten sind: Warum nicht mal an der eigenen Anwendung die Top 1000 Passwörter durchprobieren? Auch das geht auf die gleiche Weise, erschreckend einfach und führt leider häufig zum Erfolg.  

Auch hier bietet die Cheat Sheet Bibliothek von OWASP aktuelle Maßnahmen für einen Schutz.  

Auto Assignment 

Einige Software-Frameworks erlauben es, JSON und XML-Strukturen direkt auf Klassen zu Mappen. Das macht es sehr einfach, einen Request aus dem Web entgegen zu nehmen und direkt als Objekt in der Programmiersprache weiter zu verarbeiten. Dabei muss aber berücksichtigt werden, dass alles gemappt wird, was gemappt werden kann. 

Auf diese Weise kann ein Angreifer weitere Daten einschmuggeln, die der Entwickler nie vorgesehen hat. Im schlimmsten Fall kann das ein isAdmin: true sein, um ein neues Konto mit Administratorrechten anzulegen.

Hacking Playground 

Wer jetzt Lust bekommen hat, sich stärker mit Hacking und Cybersecurity zu befassen, muss das nicht zwangsläufig an der eigenen App machen. Es gibt eine Vielzahl spannender Web-Anwendungen, die zu Trainingszwecken ganz bewusst Sicherheitslücken enthalten. Eine der populärsten darunter ist der OWASP Juice Shop, ein echter Saftladen als Onlineshop. Mit rund hundert klar definierten Sicherheitslücken lassen sich sowohl einfache als auch komplexe Szenarien ausprobieren. Und das Gute ist, dank Gamification-Ansatzes wird man sogar informiert, wenn man eine der Lücken gefunden hat. 

Das vorbereitete Docker Image lässt sich mit einem Einzeiler starten: 

docker run -p 3000:3000 bkimminich/juice-shop  

Die beste Herangehensweise ist, den Shop erstmal so zu benutzen, wie er gedacht ist und dabei alles zu notieren, was einem auffällt. Welche Verzeichnisstrukturen verwendet er, welche Programmiersprachen kommen wohl zum Einsatz, welche User, Rechte und Rollen gibt es und was kann ich aus den Requests ableiten und erkennen? 

Mit dem Wissen sollte man bereits überlegen können, wo Input möglich ist, den man auf eine SQL-Injection prüfen kann, welche Verzeichnisse sich vielleicht erraten lassen und welche zusätzlichen Felder ich in Requests einschmuggeln kann, um das Backend auszutricksen. Durch diesen Perspektivenwechseln schärft man seinen Blick für typische Sicherheitslücken in Webanwendungen. Und kann bei der eigenen Software besser darauf achten, dass sie nicht anfällig ist.

Wie hast du heute schon für mehr Sicherheit in deiner Software gesorgt?

---

Über den Autor