Das Problem bei Webanwendungen ist, dass sie offen Milliarden von Internetnutzern ausgesetzt sind, von denen viele die Sicherheitsmaßnahmen brechen wollen – aus welchen Gründen auch immer.

In den Anfängen des Internets war eine der häufigsten Angriffsmethoden die einfache Brute-Force-Methode. Diese Angriffe wurden in der Regel von Bots ausgeführt – oder von Personen mit viel Freizeit -, die Zillionen von Kombinationen von Benutzernamen und Passwörtern ausprobierten, bis sie eine fanden, die den Zugriff auf die Zielanwendung ermöglichte.

Brute-Force-Angriffe sind dank Passwortrichtlinien, begrenzter Anmeldeversuche und Captchas keine Gefahr mehr. Aber Cyberkriminelle lieben es, neue Schwachstellen zu entdecken und sie für neue Arten von Angriffen zu nutzen. Schon vor langer Zeit entdeckten sie, dass Textfelder in Anwendungen oder Webseiten ausgenutzt werden können, indem sie unerwarteten Text eingeben oder injizieren, der die Anwendung dazu zwingt, etwas zu tun, was sie nicht tun soll. Auf diese Weise wurden die sogenannten Injektionsangriffe ins Leben gerufen.

Injektionsangriffe können nicht nur dazu verwendet werden, sich in eine Anwendung einzuloggen, ohne den Benutzernamen und das Passwort zu kennen, sondern auch, um private, vertrauliche oder sensible Informationen preiszugeben oder sogar einen ganzen Server zu kapern. Deshalb stellen diese Angriffe nicht nur eine Bedrohung für Webanwendungen dar, sondern auch für die Benutzer, deren Daten in diesen Anwendungen gespeichert sind, und im schlimmsten Fall für andere verbundene Anwendungen und Dienste.

Code-Injektion

Code-Injektion ist eine der häufigsten Arten von Injektionsangriffen. Wenn Angreifer die Programmiersprache, das Framework, die Datenbank oder das Betriebssystem kennen, das von einer Webanwendung verwendet wird, können sie über Texteingabefelder Code einspeisen, um den Webserver zu zwingen, das zu tun, was sie wollen.

Diese Art von Injektionsangriffen ist bei Anwendungen möglich, bei denen die Validierung der Eingabedaten fehlt. Wenn Benutzer in ein Texteingabefeld eingeben können, was sie wollen, ist die Anwendung potenziell angreifbar. Um diese Angriffe zu verhindern, muss die Anwendung die Eingaben, die Benutzer eingeben dürfen, so weit wie möglich einschränken.

Zum Beispiel muss sie die Menge der erwarteten Daten begrenzen, das Datenformat vor der Annahme prüfen und die Menge der zulässigen Zeichen einschränken.

Die Schwachstellen für die Code-Injektion lassen sich leicht finden, indem Sie einfach die Texteingabe einer Webanwendung mit verschiedenen Arten von Inhalten testen. Wenn sie gefunden werden, sind die Schwachstellen mäßig schwer auszunutzen. Wenn es einem Angreifer jedoch gelingt, eine dieser Schwachstellen auszunutzen, kann dies zu einem Verlust der Vertraulichkeit, Integrität, Verfügbarkeit oder der Anwendungsfunktionalität führen.

SQL-Injektion

Ähnlich wie bei der Code-Injektion wird bei diesem Angriff ein SQL-Skript – die von den meisten Datenbanken zur Durchführung von Abfragen verwendete Sprache – in ein Texteingabefeld eingefügt. Das Skript wird an die Anwendung gesendet, die es direkt in ihrer Datenbank ausführt. Dadurch kann der Angreifer einen Anmeldebildschirm passieren oder noch gefährlichere Dinge tun, wie z.B. sensible Daten direkt aus der Datenbank lesen, Datenbankdaten ändern oder zerstören oder Verwaltungsoperationen in der Datenbank ausführen.

PHP- und ASP-Anwendungen sind aufgrund ihrer älteren funktionalen Schnittstellen anfällig für SQL-Injection-Angriffe. J2EE- und ASP.Net-Anwendungen sind in der Regel besser gegen diese Angriffe geschützt. Wenn eine SQL-Injection-Schwachstelle gefunden wird – und das ist nicht schwer -, wird das Ausmaß der möglichen Angriffe nur durch die Fähigkeiten und die Phantasie des Angreifers begrenzt. Daher sind die Auswirkungen eines SQL-Injection-Angriffs zweifellos groß.

Befehlsinjektion

Diese Angriffe sind ebenfalls möglich, hauptsächlich aufgrund einer unzureichenden Eingabevalidierung. Sie unterscheiden sich von Code-Injection-Angriffen dadurch, dass der Angreifer Systembefehle anstelle von Programmiercode oder Skripten einfügt. Daher muss der Hacker die Programmiersprache, auf der die Anwendung basiert, oder die von der Datenbank verwendete Sprache nicht kennen. Aber sie müssen das Betriebssystem kennen, das auf dem Hosting-Server verwendet wird.

Die eingefügten Systembefehle werden vom Host-Betriebssystem mit den Privilegien der Anwendung ausgeführt, was unter anderem die Offenlegung des Inhalts beliebiger Dateien auf dem Server, die Anzeige der Verzeichnisstruktur eines Servers und die Änderung von Benutzerpasswörtern ermöglichen könnte.

Diese Angriffe können von einem Systemadministrator verhindert werden, indem er die Systemzugriffsebene der auf einem Server laufenden Webanwendungen einschränkt.

Site-übergreifendes Scripting

Wann immer eine Anwendung Eingaben eines Benutzers in die von ihr erzeugte Ausgabe einfügt, ohne sie zu validieren oder zu kodieren, bietet sie einem Angreifer die Möglichkeit, bösartigen Code an einen anderen Endbenutzer zu senden. Cross-Site Scripting (XSS)-Angriffe nutzen diese Gelegenheit, um bösartige Skripte in vertrauenswürdige Websites einzuschleusen, die schließlich an andere Benutzer der Anwendung gesendet werden, die zu Opfern des Angreifers werden.

Der Browser des Opfers führt das bösartige Skript aus, ohne zu wissen, dass es nicht vertrauenswürdig sein sollte. Daher wird der Browser dem Skript den Zugriff auf Sitzungstoken, Cookies oder vertrauliche Informationen ermöglichen, die im Browser gespeichert sind. Wenn sie richtig programmiert sind, können die Skripte sogar den Inhalt einer HTML-Datei umschreiben.

XSS-Angriffe lassen sich im Allgemeinen in zwei verschiedene Kategorien einteilen: gespeicherte und reflektierte Angriffe.

Bei gespeicherten XSS-Angriffen befindet sich das bösartige Skript dauerhaft auf dem Zielserver, in einem Nachrichtenforum, in einer Datenbank, in einem Besucherprotokoll usw. Das Opfer erhält es, wenn sein Browser die gespeicherten Informationen anfordert. Bei reflektierten XSS-Angriffen wird das bösartige Skript in einer Antwort reflektiert, die die an den Server gesendete Eingabe enthält. Dies kann zum Beispiel eine Fehlermeldung oder ein Suchergebnis sein.

XPath-Injektion

Diese Art von Angriff ist möglich, wenn eine Webanwendung die von einem Benutzer bereitgestellten Informationen verwendet, um eine XPath-Abfrage für XML-Daten zu erstellen. Die Funktionsweise dieses Angriffs ähnelt der von SQL Injection: Angreifer senden missgestaltete Informationen an die Anwendung, um herauszufinden, wie die XML-Daten strukturiert sind, und greifen dann erneut an, um auf diese Daten zuzugreifen.

XPath ist eine Standardsprache, mit der Sie wie bei SQL die Attribute angeben können, nach denen Sie suchen möchten. Um eine Abfrage auf XML-Daten durchzuführen, verwenden Webanwendungen Benutzereingaben, um ein Muster festzulegen, dem die Daten entsprechen sollen. Durch das Senden von fehlerhaften Eingaben kann sich das Muster in eine Operation verwandeln, die der Angreifer auf die Daten anwenden möchte.

Anders als bei SQL gibt es bei XPath keine verschiedenen Versionen. Das bedeutet, dass XPath Injection in jeder Webanwendung, die XML-Daten verwendet, durchgeführt werden kann, unabhängig von der Implementierung. Das bedeutet auch, dass der Angriff automatisiert werden kann. Im Gegensatz zu SQL Injection kann er also auf eine beliebige Anzahl von Zielen abgefeuert werden.

Mail-Befehlsinjektion

Diese Angriffsmethode kann verwendet werden, um E-Mail-Server und -Anwendungen auszunutzen, die IMAP- oder SMTP-Anweisungen mit nicht ordnungsgemäß validierten Benutzereingaben erstellen. Gelegentlich verfügen IMAP- und SMTP-Server nicht über einen starken Schutz gegen Angriffe, wie es bei den meisten Webservern der Fall ist, und können daher leichter ausgenutzt werden. Bei der Eingabe über einen Mailserver könnten Angreifer Einschränkungen wie Captchas, eine begrenzte Anzahl von Anfragen usw. umgehen.

Um einen SMTP-Server auszunutzen, benötigen Angreifer ein gültiges E-Mail-Konto, um Nachrichten mit eingeschleusten Befehlen zu versenden. Wenn der Server verwundbar ist, wird er auf die Anfragen der Angreifer reagieren, so dass diese z. B. Serverbeschränkungen umgehen und seine Dienste zum Versenden von Spam nutzen können.

IMAP-Injektionen können vor allem bei Webmail-Anwendungen durchgeführt werden, indem die Funktion zum Lesen von Nachrichten ausgenutzt wird. In diesen Fällen kann der Angriff durchgeführt werden, indem einfach eine URL mit den injizierten Befehlen in die Adressleiste eines Webbrowsers eingegeben wird.

CRLF-Injektion

Das Einfügen von Wagenrücklauf- und Zeilenvorschubzeichen – eine Kombination, die als CRLF bekannt ist – in Eingabefelder von Webformularen stellt eine Angriffsmethode dar, die als CRLF-Injektion bezeichnet wird. Diese unsichtbaren Zeichen kennzeichnen das Ende einer Zeile oder das Ende eines Befehls in vielen herkömmlichen Internetprotokollen wie HTTP, MIME oder NNTP.

Das Einfügen eines CRLFs in eine HTTP-Anfrage, gefolgt von einem bestimmten HTML-Code, könnte zum Beispiel benutzerdefinierte Webseiten an die Besucher einer Website senden.

Dieser Angriff kann mit anfälligen Webanwendungen durchgeführt werden, die die Benutzereingaben nicht richtig filtern. Diese Sicherheitslücke öffnet die Tür für andere Arten von Injektionsangriffen wie XSS und Code-Injektion und könnte auch dazu führen, dass eine Website gekapert wird.

Host Header Injektion

Bei Servern, die viele Websites oder Webanwendungen hosten, wird der Host-Header benötigt, um zu bestimmen, welche der residenten Websites oder Webanwendungen – jede von ihnen wird als virtueller Host bezeichnet – eine eingehende Anfrage verarbeiten soll. Der Wert des Headers teilt dem Server mit, an welchen der virtuellen Hosts er eine Anfrage senden soll. Wenn der Server einen ungültigen Host-Header erhält, leitet er die Anfrage normalerweise an den ersten virtuellen Host in der Liste weiter. Dies stellt eine Schwachstelle dar, die Angreifer nutzen können, um beliebige Host-Header an den ersten virtuellen Host eines Servers zu senden.

Die Manipulation des Host-Headers steht in der Regel im Zusammenhang mit PHP-Anwendungen, kann aber auch mit anderen Web-Entwicklungstechnologien durchgeführt werden. Host-Header-Angriffe fungieren als Wegbereiter für andere Arten von Angriffen, wie z.B. Web-Cache Poisoning. Die Folgen können die Ausführung sensibler Operationen durch die Angreifer sein, z. B. das Zurücksetzen von Passwörtern.

LDAP-Injektion

LDAP ist ein Protokoll, das die Suche nach Ressourcen (Geräte, Dateien, andere Benutzer) in einem Netzwerk erleichtern soll. Es ist sehr nützlich für Intranets und kann, wenn es als Teil eines Single Sign-On-Systems verwendet wird, zur Speicherung von Benutzernamen und Kennwörtern eingesetzt werden. Bei LDAP-Abfragen werden spezielle Steuerzeichen verwendet, die sich auf die Steuerung des Systems auswirken. Angreifer können möglicherweise das beabsichtigte Verhalten einer LDAP-Abfrage ändern, wenn sie Steuerzeichen in die Abfrage einfügen können.

Auch hier ist das Grundproblem, das LDAP-Injection-Angriffe ermöglicht, die nicht ordnungsgemäß validierte Benutzereingabe. Wenn der Text, den ein Benutzer an eine Anwendung sendet, als Teil einer LDAP-Abfrage verwendet wird, ohne ihn zu bereinigen, könnte die Abfrage am Ende eine Liste aller Benutzer abrufen und sie einem Angreifer zeigen, indem er einfach ein Sternchen (*) an der richtigen Stelle in einer Eingabezeichenfolge verwendet.

Verhinderung von Injektionsangriffen

Wie wir in diesem Artikel gesehen haben, richten sich alle Injektionsangriffe gegen Server und Anwendungen, die für jeden Internetnutzer zugänglich sind. Die Verantwortung für die Verhinderung dieser Angriffe liegt bei den Anwendungsentwicklern und Serveradministratoren.

Anwendungsentwickler müssen die Risiken kennen, die mit der fehlerhaften Validierung von Benutzereingaben verbunden sind, und bewährte Verfahren zur Bereinigung von Benutzereingaben erlernen, um Risiken zu vermeiden. Serveradministratoren müssen ihre Systeme regelmäßig überprüfen, um Schwachstellen zu erkennen und sie so schnell wie möglich zu beheben. Es gibt viele Möglichkeiten, diese Audits durchzuführen, entweder bei Bedarf oder automatisch.