© ideyweb/Shutterstock.com
Teil 1: Injection-Schwachstellen im Überblick

Zehn Bedrohungen für Webanwendungen


Die Non-Profit-Organisation Open Web Application Security Project (OWASP) hat im Herbst 2017 ihre Top 10 der größten Bedrohungen für Webanwendungen veröffentlicht. In diesem Artikel lernen Sie den ersten Platz kennen: Injection-Schwachstellen. Eine ernstzunehmende Sicherheitslücke, vor der man sich mit den richtigen Maßnahmen schützen kann.

Die Veröffentlichung der neuen OWASP Top 10 lief etwas holprig: Am 2. Mai 2016 wurde ein Data Call zum Sammeln von Informationen über Schwachstellen in Webanwendungen veröffentlicht [1]. Erst ein Jahr später, am 2. Mai 2017, war ein erster Release Candidate fertig [2], [3]. An dem Release Candidate gab es heftige Kritik, u. a. weil mit „Insufficient Attack Protection (A7)“ ein neuer Aspekt auf der Liste war, der mit dem eigentlichen Thema, den Schwachstellen in Webanwendungen, nichts direkt zu tun hat. Stattdessen ging es darin um die Erkennung und Abwehr von Angriffen durch zusätzliche Schutzmaßnahmen wie eine Web Application Firewall. Und auch der zweite neue Punkt, „Underprotected APIs (A10)“, war nicht unumstritten. Außerdem gab es Kritik an der Datensammlung. 2013 wurden als relevant angesehenen Unternehmen, Bildungseinrichtungen und Personen direkt angesprochen. 2016 gab es zusätzlich noch einen offenen Aufruf, was insgesamt dazu führte, dass die gesammelten Daten nicht ausgewogen genug waren [4]. Am 2. August übernahm dann ein neues Team die Zusammenstellung der neuen Top 10 [5]. Am 20. Oktober wurde der zweite Release Candidate veröffentlicht [6], [7] und am 20. November folgte dann endlich die finale Version [8].

Die neuen OWASP Top 10

Im Vergleich zu den OWASP Top 10 von 2013 gibt es die folgenden Änderungen [9]:

  • Einige Einträge haben ihre Plätze gewechselt:Der Punkt „Cross Site Scripting (XSS)“ ist von Platz 3 (2013) auf Platz 7 (2017) abgestiegen.Der Punkt „Security Misconfiguration“ ist von Platz 5 auf Platz 6 abgestiegen. Dafür ist der Punkt „Sensitive Data Exposure“ von Platz 6 auf Platz 3 aufgestiegen.

  • Die Punkte „Insecure Direct Object References“ (2013: Platz 4) und „Missing Function Level Access Control“ (2013: Platz 7) wurden auf Platz 5 als „Broken Access Control“ zusammengefasst.

  • Die Punkte „Cross-Site Request Forgery (CSRF)“ (2013: Platz 8) und „Unvalidated Redirects and Forwards“ (Platz 10) wurden aus den OWASP Top 10 2017 gestrichen, da sie nur noch in ca. fünf bzw. acht Prozent der Anwendungen gefunden wurden.

  • Neu sind die Punkte „XML External Entity (XXE)“ (Platz 4), „Insecure Deserialization“ (Platz 8) und „Insufficient Logging & Monitoring“ (Platz 10).

Damit sehen die aktuellen OWASP Top 10 so aus:

  • A1:2017 – Injection

  • A2:2017 – Broken Authentication

  • A3:2017 – Sensitive Data Exposure

  • A4:2017 – XML External Entities (XXE)

  • A5:2017 – Broken Access Control

  • A6:2017 – Security Misconfiguration

  • A7:2017 – Cross-Site Scripting (XSS)

  • A8:2017 – Insecure Deserialization

  • A9:2017 – Using Components with Known Vulnerabilities

  • A10:2017 – Insufficient Logging & Monitoring

Es lohnt sich, einen ausführlichen Blick auf den ersten Platz, „Injection“, zu werfen.

Platz 1: Injection

Injection-Schwachstellen entstehen, wenn nicht vertrauenswürdige Daten als Teil eines Befehls oder einer Abfrage von einem Interpreter verarbeitet werden. Ein Angreifer kann die Eingabedaten dann so manipulieren, dass er zum Beispiel nicht vorgesehene Befehle ausführen oder unautorisiert auf Daten zugreifen kann.

Um Injection-Schwachstellen zu verhindern, müssen Sie Eingabedaten und Befehle konsequent trennen, sodass die Befehle nicht über die Eingabedaten manipuliert werden können. Dazu können Sie z. B. APIs verwenden, die den Aufruf der entsprechenden Interpreter vermeiden oder eine typgebundene Schnittstelle zur Verfügung stellen.

Steht kein typsicheres API zur Verfügung, müssen Sie selbst dafür sorgen, dass keine schädlichen Eingaben interpretiert werden. Dazu können Sie z. B. die für den jeweiligen Interpreter relevanten Metazeichen herausfiltern oder maskieren. Eventuell können Sie auch alle zulässigen harmlosen Eingaben auf eine Whitelist setzen und alles andere, was nicht als erwünscht darauf steht, verwerfen. Konkret gibt es die folgenden Injection-Schwachstellen.

SQL Injection

SQL-Injection-Schwachstellen entstehen, wenn Benutzereingaben mit vorhandenen SQL-Abfragefragmenten zu einer SQL-Abfrage kombiniert werden, zum Beispiel nach dem Muster

$abfrage = "SELECT * FROM benutzer_tabelle WHERE name='".$_GET['Name']."'";

Gibt ein Angreifer als Wert für den Parameter Name zum Beispiel 'Alice' or '1'='1' ein, ergibt das die Abfrage

SELECT * FROM benutzer_tabelle WHERE name='Alice' or '1'='1'

die zur Ausgabe aller Datensätze der Tabelle benutzer_tabelle führt.

Der Angreifer kann durch entsprechende Manipulationen an den Abfragen nahezu beliebig Daten aus der Datenbank abfragen, die von der Anwendung dann zusammen mit den erwarteten Daten ausgegeben werden. Außer Daten abzufragen können unter Umständen auch Daten eingeschleust werden, was im schlimmsten Fall zum Einschleusen von schadhaftem PHP-Code führen kann.

SQL Injection verhindern

Wie oben schon erwähnt, besteht die sicherste Lösung im Allgemeinen in der Nutzung eines sicheren API. Im Fall der SQL Injection ist auch die Verwendung von parametrisierten Aufrufen (Parameterized Queries) von Prepared Statements mit Parameterbindung sicher. Der Aufbau des SQL-Statements wird dabei in zwei Schritte aufgeteilt:

  • Die Struktur des SQL-Statements wird definiert, für alle Eingaben werden Platzhalter eingesetzt.

  • Der Inhalt der Platzhalter wird spezifiziert.

Die im zweiten Schritt erzeugten Daten haben keine Möglichkeit die im ersten Schritt definierte Struktur des Statements zu ändern. Nachdem die Struktur des Statements definiert wurde, werden alle für die Platzhalter übergebenen Eingaben als Daten und nicht als Teil der Statementstruktur betrachtet. Schleust ein Angreifer SQL-Code ein, wird er nicht ausgeführt.

Prepared Statements in PHP

In PHP werden Prepared Statements z. B. von der MySQLi Extension bereit gestellt. Die SQL-Abfrage wird mit der Funktion mysqli_prepare() vorbereitet, danach werden die Parameter mit der Funktion mysqli_stmt_bind_param() daran gebunden. Das so vorbereitete...

Neugierig geworden? Wir haben diese Angebote für dich:

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