© saicle/Shutterstock.com
Die zehn größten Sicherheitslücken im Web in drei Teilen

Security Patterns


Nicht erst seit dem NSA-Skandal ist Security wieder ein Thema. Erst kürzlich wurde vom Ponemon Institute eine Umfrage veröffentlicht [1], in der 73 Prozent der befragten Unternehmen zugaben, mindestens einmal in den letzten zwei Jahren gehackt worden zu sein. Da ein Großteil der Sicherheitslücken auf dem Web Application Layer zu finden ist, wollen wir in den nächsten Ausgaben einige der Hauptprobleme aufzeigen und Lösungen dafür anbieten.

Doch was sind denn die wichtigsten Sicherheitsprobleme? Dieser Frage hat sich das Open Web Application Security Project (kurz OWASP [2], Kasten: „OWASP“) gewidmet, das bisher alle drei Jahre eine Top-10-Liste der riskantesten Sicherheitslücken erstellt hat.

Die aktuelle Version wurde 2013 veröffentlicht und um nicht nur aufzuzeigen, wie groß denn der technische Impact ist, wurde eine Einstufung nach Risiken vorgenommen. Hier ist unter anderem dann auch die wirtschaftliche Sicht berücksichtigt:

  • Wie hoch ist der finanzielle Schaden?

  • Kann das Ausnutzen der Lücke zu einem Reputationsverlust führen?

  • Wie viele persönliche/sensitive Daten können veröffentlicht werden?

OWASP

OWASP ist eine Non-Profit-Vereinigung mit verschiedenen Chapters, meist nach Ländern organisiert und über den ganzen Globus verteilt. Zudem hat zum Beispiel der Germany Chapter weitere Unterteilungen in diverse lokale Gruppen, wie z. B. im Rhein-Main-Gebiet oder Hamburg. Diese treffen sich dann in regelmäßigen Abständen und tauschen sich über aktuelle Sicherheitsthemen aus. Die meisten Mitglieder kommen bisher aus der Java-Welt, aber auch PHP-Entwickler sind herzlich willkommen. Wir werden dann zunächst zwar erst belächelt, aber es ist unsere Aufgabe, die Fahne hochzuhalten und aufzuzeigen, dass uns das Thema ernst ist!

Neben dem riesigen Wiki auf der OWASP-Website [2] mit über 1 000 Mitgliedern gibt es auch zahlreiche Mailing-Listen zu diversen Themen, professionell produzierte Videos von Talks und veranschaulichte Erklärungen der Sicherheitslücken sowie Events, die gemeinnützig veranstaltet werden. Die bekannteste europäische Veranstaltung ist dabei sicherlich die AppSecEU, die 2013 in Hamburg stattfand und im Juni 2014 in Cambridge zu Gast sein wird. Die Liste der Speaker ist dabei international und sehr hochkarätig besetzt.

Die OWASP arbeitet an einer ganzen Liste von Projekten, wie z. B. einem XSS-Tool, dem Zed Attack Proxy [3] oder Webgoat [4], eine Webanwendung, die beabsichtigt unsicher programmiert wurde, um so eine praktische Anleitung zu bieten, sichereren Code zu schreiben.

Neben der globalen Top-10-Liste [5] gibt es auch noch einen Ableger für Mobile Development [6], der sich speziell an Produzenten für mobile Apps richtet und aktuell ist eine OWASP Top 10 für Entwickler [7] in Arbeit, die sich speziell an uns richtet und u. a. auch mit mehr technischem Background und Codebeispielen in möglichst vielen Sprachen aufwarten soll.

Den ersten Sicherheitslücken der OWASP Top 10 wollen wir uns nun in diesem ersten Beitrag einer Serie über mehrere Ausgaben widmen.

Injection

SQL Injections sind inzwischen fast jedem Entwickler ein Begriff und die Statistiken zu erfolgreichen Angriffen auf diesem Gebiet sind zum Glück rückläufig, aber leider immer noch hoch. Deswegen soll das Thema dennoch angeschnitten werden, bevor wir uns weiteren (Nicht-SQL-)Injections widmen.

Ein großes Problem bei SQL Injections ist, dass der SQL-Interpreter zunächst nur alle Strings bis zum Auftreten eines Semikolons verarbeitet und diese dann direkt ausführt, ohne den nachfolgenden String zu überprüfen. Nehmen wir folgendes Beispiel an, in dem die E-Mail-Adresse eines Users aktualisiert werden soll:

$sql = 'UPDATE users SET email = "'.$email.'" WHERE id=123';

Wird nun der Parameter $email nicht weiter validiert, kann über diesen beliebiger Code an den SQL Server geschickt werden und damit Daten manipuliert, gelöscht oder ausspioniert werden. Die doppelten Anführungszeichen sollen eigentlich den Werteteil der E-Mail-Adresse abtrennen, aber natürlich kann auch dieses Anführungszeichen entsprechend in der Variable stehen und somit seinen vorbestimmten Scope verlassen.

Angenommen in der Variable $email stehen nur zwei Zeichen: Ein Anführungszeichen und ein Semikolon. So sieht der String, der an den SQL Server gesendet wird, folgendermaßen aus:

UPDATE users SET email="";" WHERE id=123

Und dies ist zumindest bis zum Semikolon vollkommen valider SQL-Code, der aber leider nicht die E-Mail-Adresse des Users 123 aktualisiert, sondern sämtliche E-Mail-Adressen aus der Tabelle users entfernt, da das Statement nach dem Semikolon zu Ende ist. Dass danach invalider SQL-Code steht, interessiert den Interpreter in dem Moment noch gar nicht. Zudem kann natürlich auch dies durch eine größere Manipulation der $email-Variable gelöst werden, sodass offensichtlich nicht mal ein Fehler auftritt und auch ein entsprechender Logging-Mechanismus nichts von dieser Manipulation mitbekommt. Denken Sie z. B. an folgende Manipulation:

$email = ‚";UPDATE users SET email="' . $email;

Dies würde sogar alle E-Mail-Adressen aus der Tabelle löschen und keinerlei SQL-Fehler erzeugen, aber die ursprüngliche Änderung der einen E-Mail-Adresse dennoch ausführen, sodass der Angriff noch weniger auffällt. Abbildung 1 zeigt, wie der aktuelle Response-Header von reddit.com versucht, eine SQL Injection bei entsprechenden Crawlern auszulösen.

zander_owasp_1.tif_fmt1.jpg Abb. 1: Der aktuelle Response-Header von reddit.com versucht, eine SQL Injection bei entsprechenden Crawlern auszulösen

Neben dem Löschen von Daten können diese natürlich auch einfach nur manipuliert werden. So können z. B. sensitive E-Mails an einen anderen Empfänger geschickt oder Passwörter überschrieben werden. Die gefährlichste Attacke ist dabei immer diejenige, die zunächst g...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang