A03:2021 – Injection

Beurteilungskriterien

Zugeordnete CWEs	Maximale Häufigkeit	Durchschn. Häufigkeit	Durchschn. Ausnutzbarkeit (gewichtet)	Durchschn. Auswirkungen (gewichtet)	Maximale Abdeckung	Durchschnittliche Abdeckung	Gesamtanzahl	CVEs insgesamt
33	19.09 %	3.37 %	7.25	7.15	94.04 %	47.90 %	274,228	32,078

Übersicht

Die Injection rutscht von der ersten auf die dritte Position ab. 94 % der Anwendungen wurden auf irgendeine Form der Injection getestet, mit einer maximalen Häufigkeit von 19,09 %, einer durchschnittlichen Häufigkeit von 3,37 % und über 274.000 Vorkommnissen. Zu den wichtigsten Common Weakness Enumerations (CWEs) zählen CWE-79: Cross-Site Scripting, CWE-89: SQL Injection und CWE-73: External Control of File Name or Path.

Beschreibung

Eine Anwendung ist für diesen Angriff anfällig, wenn:

Daten, die von Nutzenden stammen, von der Anwendung nicht ausreichend validiert, gefiltert oder bereinigt werden.
Dynamische Anfragen oder nicht-parametrisierte Aufrufe ohne ein, dem Kontext entsprechendes Escaping direkt einem Interpreter übergeben werden.
Bösartige Daten innerhalb von ORM („Object-Relational Mapping“)-Suchparametern genutzt werden können, um vertrauliche Datensätze von Dritten zu extrahieren.
Bösartige Daten direkt oder als Teil zusammengesetzter, dynamischer Querys verwendet werden. Die SQL-Abfragen oder Befehle beinhalten die Struktur und die schädlichen Daten in den dynamischen Querys, Befehlen oder Stored Procedures.

Zu den häufigeren Injection Arten gehören SQL, NoSQL, OS-Befehle, Object Relational Mapping (ORM), LDAP und Expression Language (EL) oder Object Graph Navigation Library (OGNL). Das Grundkonzept eines Injection-Angriffs ist für alle Interpreter gleich. Ein Quellcode-Review ist die beste Methode, um Injection-Schwachstellen in Anwendungen zu finden. Ausführliches (ggf. automatisiertes) Testen aller Parameter und Variablen, Header-, URL-, Cookies-, JSON-, SOAP- und XML-Eingaben wird dringend empfohlen. Statische (SAST, Quellcode-Ebene), dynamische (DAST, laufende Anwendung) und interaktive (IAST, Mischform aus statisch und dynamisch) Test-Werkzeuge können von Organisationen für ihre CI/CD-Pipeline genutzt werden, um neue Schwachstellen noch vor einer möglichen Auslieferung in Produktivsysteme zu identifizieren.

Prävention und Gegenmaßnahmen

Eine konsequente Trennung von Daten, Suchanfragen und Befehlen ist für die Vermeidung von Injection-Angriffen unerlässlich:

Die bevorzugte Methode ist die Verwendung einer sicheren API, die die Verwendung des Interpreters vollständig vermeidet, eine parametrisierte Schnittstelle bereitstellt oder in objektrelationale Mapping-Tools (ORMs) umwandelt.
Anmerkung: Stored Procedures können - auch parametrisiert - immer noch SQL-Injections ermöglichen, wenn PL/SQL oder T-SQL Anfragen und Eingabedaten konkateniert oder mit EXECUTE IMMEDIATE oder exec() ausgeführt werden.
Für die serverseitige Eingabe-Validierung empfiehlt sich die Nutzung eines Positivlisten(“Whitelist”)-Ansatzes. Dies ist i. A. kein vollständiger Schutz, da viele Anwendungen Sonderzeichen z. B. in Textfelder oder APIs für mobile Anwendungen benötigen.
Für jede noch verbliebene dynamische Query müssen Sonderzeichen für den jeweiligen Interpreter mit der richtigen Escape-Syntax entschärft werden.
Anmerkung: Ein Escaping von SQL-Bezeichnern, wie z. B. die Namen von Tabellen oder Spalten usw. ist nicht möglich. Falls Nutzende solche Bezeichner selbst eingeben können, so ist dies durchaus gefährlich. Dies ist eine übliche Schwachstelle bei Software, die Reports aus einer Datenbank erstellt.
SQL-Querys sollten LIMIT oder andere SQL-Controls verwenden, um den möglichen Massen-Abfluss von Daten zu verhindern.

Beispielhafte Angriffsszenarien

Szenario Nr. 1: Eine Anwendung nutzt ungeprüfte Eingabedaten für den Zusammenbau der folgenden verwundbaren SQL-Abfrage:

String query = "SELECT \* FROM Accounts WHERE custID='" + request.getParameter("id") + "'";

Szenario Nr. 2: Auch das blinde Vertrauen in Frameworks kann zu Querys führen, die ganz analog zu obigem Beispiel verwundbar sind (z. B. Hibernate Query Language (HQL)):

Abfrage HQLQuery = session.createQuery("FROM Accounts WHERE custID='" + request.getParameter("id") + "'");

In beiden Fällen können Angreifende den ‘id’-Parameter im Browser ändern und sendet: „UNION SLEEP(10);--“. Zum Beispiel:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

Hierdurch wird die Logik der Anfrage verändert, so dass alle Datensätze der Tabelle „accounts“ ohne Einschränkung auf einen Kunden zurückgegeben werden. Gefährlichere Attacken wären z. B. das Ändern oder Löschen von Daten oder das Aufrufen von Stored Procedures.