In diesem Beitrag aus unserer Reihe zur OWASP Top Ten, den häufigsten Sicherheitslücken in Webapplikationen, beschäftigen wir uns mit Injections, also „Injektionen“.
Injection-Sicherheitslücken nutzen eine ungesicherte Verarbeitung von Nutzereingaben aus, z.B. in Eingabefeldern für Namen und Adressen. Statt die vorgesehenen Daten einzugeben, kann ein Angreifer z.B. Programmcode oder Datenbankbefehle in das Feld eingeben. Eine unsichere Webapplikation interpretiert diese Eingabe und führt den eingegebenen Code aus, statt die Eingabe auf ihre Gültigkeit zu überprüfen und ggf. zu verwerfen. Injections werden je nach Art des übermittelten Schadcodes unterschieden.
SQL-Injection
Die am häufigsten auftretende Injection-Attacke, welche auch am häufigsten für den Datenverlust von unzähligen Kundendatensätzen verantwortlich ist, wird als SQL-Injection bezeichnet. SQL steht für „Structured Query Language“ und ist eine Sprache zur Datenbankabfrage. Ein SQL-Statement sieht z.B. so aus:
SELECT * FROM Kunden WHERE Kundennummer = X;
Dieses Beispiel sucht aus der Kunden-Tabelle den Datensatz heraus, der die Kundennummer X hat, wobei X frei durch den Benutzer der Suche gewählt werden kann. Wenn der Nutzer beispielsweise nach der Kundennummer 89075 sucht, würde das exakte SQL-Statement folgendermaßen aussehen:
SELECT * FROM Kunden WHERE Kundennummer = 89075;
SQL bietet noch wesentlich mehr Funktionen als diese einfache Suche und beinhaltet auch Funktionen zum Bearbeiten von Datensätzen.
Der Trick an einer SQL-Injection ist nun, dass ein Angreifer hinter einem Eingabefeld (z.B. für die Suche von Kunden nach Kundennummer) ein SQL-Statement wie oben vermutet: Die Webapplikation fügt die vom Benutzer in das Feld eingegebene Kundennummer in das Statement ein. Gibt der Angreifer statt einer korrekten Kundennummer jetzt aber z.B. „89075 OR 1=1“ ein, wird das folgende SQL-Statement ausgeführt:
SELECT * FROM Kunden WHERE Kundennummer = 89075 OR 1=1;
Das Statement sucht also alle Datensätze heraus, die die Kundennummer 89075 haben oder auf die die Bedingung 1=1 zutrifft. Da die Bedingung 1=1 immer zutrifft, liefert die Datenbank als Ergebnis die gesamte Kundentabelle zurück. So entstehen Datenlecks.
OS-Injection und weitere
Eine weitere, folgenschwere Lücke ist die OS-Injection, bei der ein Angreifer durch Eingabefelder in der Webapplikation Befehle an das Betriebssystem des Webservers weiterleiten kann. Dadurch kann er z.B. Dateien vom Server kopieren, löschen oder verändern, Passwörter ändern oder Schadsoftware einschleusen, die ihm permanenten Zugang zum System verschafft.
Bei einer Code-Injection kann der Angreifer über Eingabefelder Programmcode in der Programmiersprache der Webapplikation einschleusen und beliebige Befehle ausführen. Unter Umständen besteht im Kontext einer Code-Injection auch die Möglichkeit für eine OS-Injection, da viele Programmiersprachen die Möglichkeit bieten, Befehle an das Betriebssystem des Servers weiterzugeben.
Gegenmaßnahmen
Injection-Lücken kann vorgebeugt werden, in dem sämtliche Benutzereingaben validiert werden. Es gilt der Grundsatz: „Never trust user input“ – Vertraue niemals Benutzereingaben. Dies beinhaltet auch die korrekte Filterung von Sonderzeichen. Benutzereingaben oder Teile von ihnen sollten niemals direkt in Anfragen an eine Datenbank oder an das Betriebssystem verwendet werden. Weiterhin sollten SQL-Statements immer parametrisiert werden, sodass die Logik einer Abfrage durch das Einsetzen der Parameter nicht verändert werden kann.
Zusammenfassung
Injection-Attacken sind die häufigsten Sicherheitslücken, da jede Webapplikation mit Benutzereingaben arbeitet, und können die schwerwiegendsten Folgen haben. Deshalb sind sie in der OWASP Top Ten auf Platz 1 gelandet und sollten fester Bestandteil jedes Penetrationstests von Webapplikationen sein.
Der nächste Teil unserer OWASP Top Ten Reihe behandelt A2 – Fehler in Authentifizierung und Session-Management.