A03:2021 – Injektion

Injektionen sind eine Art von Schwachstelle, bei der ein Angreifer nicht vertrauenswürdige Daten über eine Anfrage oder Abfrage an einen Interpreter sendet, was zu einer Unterbrechung des Ausführungsflusses oder des ursprünglich für die Anwendung vorgesehenen Verhaltens führt. 

Auf diese Weise können Aktionen durchgeführt werden, die von der Extraktion zusätzlicher Informationen über das angegriffene System bis hin zum Diebstahl einer Benutzersitzung oder sogar der Fernausführung von Befehlen und der anschließenden Übernahme des Webservers selbst reichen, auf dem die Anwendung gehostet wird.

Injektionen wurden in den aufeinanderfolgenden Ausgaben der OWASP Top 10 als die kritischsten und konstantsten eingestuft, da sie zur absoluten Kontrolle über die Zielmaschine führen können. Tatsächlich standen sie bei allen Ausgaben bis 2021 auf Platz eins der Liste, von wo aus sie auf den dritten Platz zurückfielen.

Arten von Injektionen

Da es weitgehend vom verwendeten Interpreter, der verwendeten Sprache oder dem im Backend des Servers verwendeten Speichersystem abhängt, kann es auch zu einer erheblichen Anzahl verschiedener Injektionen kommen, wie zum Beispiel:

SQL-Injections (SQLi – SQL-Injections) 

Es ermöglicht die unerwünschte Manipulation bestehender Daten in nicht relationalen Datenbanken, die Modifizierung oder Änderung von Dateninformationen oder die Umgehung bestehender Authentifizierungs- und/oder Autorisierungssysteme. 

Im Gegensatz zu dem, was Laien normalerweise denken, handelt es sich bei solchen Injektionen nicht um eine „90er-Jahre-Sache“. Heutzutage werden immer noch Injektionen vom Typ SQL (Structured Query Language) verwendet, die bei Abfragen oder Änderungen relationaler Datenbanken verwendet werden. Ein klares Beispiel hierfür ist eine der im TSA-System (Transportation Security Administration) entdeckten Schwachstellen, die dazu geführt hat, dass die Sicherheit von 77 Fluggesellschaften, die ein bestimmtes System nutzten, ignoriert wurde die trivialsten Injektionen dieser Art. 

NoSQL-Injektionen (NoSQLi-NoSQL-Injektionen)

Mit dem Aufkommen nicht relationaler Datenbanken wie MongoDB (wo Daten in BSON gespeichert werden, einem JSON-ähnlichen Datenformat), CouchDB oder Redis ändert sich die Art der Injektion, um sich an diese Art von Informationen anzupassen, aber das Ergebnis kann genauso verheerend sein. 

Befehlsinjektionen (CI-Befehlsinjektionen)

In diesem Fall werden unerwünschte Befehle in das zugrunde liegende Betriebssystem „eingeschleust“. 

LDAP-Injektionen (LDAPi – Lightweight Directory Access Protocol-Injektionen)

In diesem Fall wird die Ausnutzung der Injektion durch die unerwünschte Manipulation von LDAP- oder Lightweight Directory Access Protocol-Abfragen verursacht, um auf Netzwerkressourcen zuzugreifen oder diese zu manipulieren, oder um die Authentifizierung von Benutzern, die diese Art von Protokoll in der Webanwendung verwenden. 

Inyecciones XML (XMLi – XML-Injektion, XXE – XML-eXternal-Entity-Injection)

In diesem Fall werden die an den Server gestellten XML-Anfragen so manipuliert, dass sie unkontrollierte Entitäten einbeziehen, sogar externe Entitäten, die vom angreifenden Computer selbst geladen werden (im Fall von XXE), um interne Dateien lesen oder sogar eine Remote-Befehlsausführung durchführen zu können. 

XPath-Injektionen

In diesem Fall wird die Manipulation von XPath-Abfragen (XML Path Language) missbraucht, um auf Daten oder Attribute in XML-Dokumenten zuzugreifen oder diese zu ändern. 

Verwendung von Cross Site Scripting (XSS – CrossSite Scripting)

Bei dieser Art von Injektionen werden sie zunächst als Injektionen auf der „Client“-Seite betrachtet, da sie hauptsächlich die Beziehung zwischen Webanwendungen und dem, was im Browser des Benutzers geschieht, beeinflussen. 

Diese Tatsache, die zunächst als nicht besonders relevant angesehen werden könnte, ist jedoch nicht der Fall, wenn man bedenkt, dass ein reflektiertes XSS zu Identitätsdiebstahlangriffen oder zum Diebstahl von Benutzersitzungen oder, im Fall von gespeicherten, zur Kompromittierung eines führen kann komplette Infrastruktur und nicht nur die Verunstaltung oder Entstellung der Webanwendung. 

Darüber hinaus können sie in Kombination mit anderen Angriffsarten (dem oben genannten SQLi oder anderen wie SSRF-Server-Side Request Forgery, CSRF oder XSRF-Cross-Site Request Forgery...) besonders gefährlich sein. 

Sie zeichnen sich durch die Verwendung von JavaScript (oder ähnlichen auf dem Client verwendeten Skriptsprachen wie vbscript, obwohl heute weniger verbreitet) und HTML (HTMLi oder HTML-Injection) aus. 

Serverseitige Vorlageninjektion (SSTI)

Mit dem Aufkommen neuer Frameworks auf Webservern wie PHP, Spring in Java, Flask/Django in Python, Express (Node.js) bis hin zu traditionellen Backends entstanden auf dem Webserver bestimmte beliebte Template-Verarbeitungs-Engines wie Jinja oder Jinja2 (Python), Twig (PHP), Pug/Jade (Node.js), EJS (JavaScript), Freemarker (Java) usw. 

Und mit ihnen neue Arten der Injektion, die diese vorhandenen Vorlagen missbrauchen, wobei ein Angreifer durch geeignete Manipulation und Injektion spezifischer Befehle mit der gesamten Serverumgebung, einschließlich vorhandener Dateien oder Dienste, oder sogar mit dem System selbst interagieren könnte. 

ORM-Injektion (Objektrelationale Mapping-Injektion)

Obwohl die Verwendung einer Abstraktionsschicht mit Objektorientierung äußerst wünschenswert ist, um Arten von SQL- oder NoSQL-Injection zu vermeiden und die direkte Konstruktion und Manipulation von SQL-Strings zu vermeiden, kann eine schlechte ORM-Implementierung zur Entdeckung von Datenbankinformationen der zugrunde liegenden Daten führen. durch die Verwendung dynamischer Abfragen, die die Logik dieser Art von Objekten manipulieren, analog zu dem, was mit einem SQLi geschehen würde. 

In diesem Sinne wurden in beliebten ORMs wie SQLAlchemy (für Python) oder Hibernate (für Java) verschiedene Formen der Injektion entdeckt. 

Code-Injektionen

Der Missbrauch dieser Art von Injektionen hängt ausschließlich von der Art der Sprache ab, die für die dynamische Codeausführung in der Webanwendung verwendet wird. Zum Beispiel PHP (mit Funktionen wie eval()) oder Python. 

String-Injektion formatieren

Hierbei handelt es sich um injizierte Funktionen im String-Format, die zur Manipulation von Benutzereingabedaten dienen und die Offenlegung unerwünschter Informationen auf der Serverseite oder die Ausführung sogar beliebigen Codes ermöglichen würden. 

Injektionen mit regulären Ausdrücken (Regex-Injektion)

Die Ausnutzung dieser Art von Injektionen ist im Allgemeinen auf die laxe Implementierung bestimmter im System verwendeter regulärer Ausdrücke zurückzuführen, die ihre Manipulation zur Durchführung von Angriffen zur Erlangung zusätzlicher Informationen, zur Umgehung von Filtern oder sogar zu Denial-of-Service-Angriffen (DoS) ermöglicht . ).

HTTP-Header-Injection

Die Injektion erfolgt in diesem Fall im HTTP-Header der an den Server gesendeten Anfragen, was andere Arten von Angriffen wie Cache-Poisoning (Cache Poisoning) oder die Manipulation von in der Anwendungssitzung verwendeten Cookies ermöglicht. 

Tatsächlich ist es üblich, auch andere Arten von Injektionen zu verwenden, die in den Kopfteilen erwähnt werden. 

Warum kommt es zu Injektionen?

Die meisten Injektionen erfolgen aus einem gemeinsamen Grund, unabhängig von der im Backend verwendeten Sprache, der bereitgestellten Infrastruktur oder der Serverkonfiguration, was die Entscheidung für die Verwendung bestimmter Injektionsarten oder anderer motivieren wird. 

Der Hauptgrund ist das Fehlen von Kontrollen für die Validierung der Benutzereingabedaten sowie die Ausgabe (oder schichtübergreifende Verarbeitung) der Informationen an den Server.

Es darf nicht vergessen werden, dass erste Anfragen nach Passieren von Filtern auf der Client-Seite abgefangen und so manipuliert werden können, dass sie sich auch auf den Server auswirken, sofern nicht speziell auf dieser Seite Kontrollen und Validierungen eingerichtet wurden.

Diese Art von Angriffen sollte auch nicht als Angriffe aufgefasst werden, die nur Webanwendungen betreffen, da viele der beschriebenen Injektionen (insbesondere SQLi) in Nicht-Web-Client-Server-Architekturen möglich sind (selbst wenn sich Client und Server auf demselben Computer befinden). .

Schadensbegrenzungsmaßnahmen

Als Hauptempfehlungen werden folgende genannt:

• In allen Eingaben, die eine Anwendung empfangen kann, muss eine Zero-Trust-Richtlinie eingerichtet werden, die eine angemessene Bereinigung gewährleistet, so dass unerwünschte Zeichen maskiert werden (wobei die Verwendung von Blacklists so weit wie möglich vermieden und durch Sicherheitsfunktionen bezüglich der Zeichenmaskierung ersetzt wird). abhängig von den verwendeten Technologien). 

• Darüber hinaus wird beim Zugriff auf Datenbankserver der Einsatz parametrisierter Abfragen unter Berücksichtigung der Sicherheitsempfehlungen des jeweiligen Datenbankanbieters sowie der verwendeten Technologie empfohlen. 

• Es müssen geeignete Datenbankabstraktionen durchgeführt werden, um die direkte Konstruktion von SQL-Abfragen durch die korrekte Verwendung von ORM (Object-Relational Mapping) zu vermeiden. 

• Unabhängig davon muss eine korrekte Zugriffskontrolle implementiert werden, die die Berechtigungen auf dem Server sowohl für den laufenden Webdienst als auch für den Zugriff auf die Datenbank oder auf die spezifischen Verzeichnisse, in denen die Anwendung ausgeführt wird, so einschränkt, dass der Zugriff möglich ist auf andere Bereiche des Servers ist stark eingeschränkt. 

Auf diese Weise werden durch die Etablierung des „Prinzips der geringsten Privilegien“ die weiteren Schritte eines möglichen Angreifers weitestgehend eingeschränkt, wenn dieser einen dieser Angriffe erfolgreich ausnutzen konnte. 

• Greifen Sie auf zusätzliche Schutzebenen zurück, wie z. B. die Ausführung einer WAF (Web Application Firewall) mit klar definierten Regeln, um diese Art von Angriffen zu stoppen, oder die Blockierung einer möglichen Automatisierung bei Einschleusungsversuchen. 

Natürlich ohne sich ausschließlich und blind auf solche Systeme zu verlassen, die auch umgangen werden können.