Webanwendungen sind einer riesigen Anzahl von Internetnutzern zugänglich, von denen einige versuchen, Sicherheitsmaßnahmen zu umgehen, aus unterschiedlichen Motiven.
In den Anfängen des Internets waren einfache Brute-Force-Angriffe eine gängige Methode. Hierbei probierten Bots oder Einzelpersonen mit viel Zeit unzählige Kombinationen von Benutzernamen und Passwörtern aus, bis sie Zugang zur Zielanwendung erhielten.
Passwortrichtlinien, begrenzte Anmeldeversuche und Captchas haben Brute-Force-Angriffe weitgehend eingedämmt. Cyberkriminelle suchen jedoch ständig nach neuen Schwachstellen. Sie entdeckten, dass Textfelder in Anwendungen manipuliert werden können, indem unerwartete Texte eingegeben werden, die die Anwendung zu unvorhergesehenen Handlungen zwingen. So entstanden Injektionsangriffe.
Injektionsangriffe ermöglichen nicht nur unbefugten Zugriff auf Anwendungen, sondern können auch private Daten preisgeben oder sogar ganze Server übernehmen. Diese Angriffe stellen somit eine Bedrohung für Webanwendungen, Benutzerdaten und im schlimmsten Fall für verbundene Anwendungen und Dienste dar.
Code-Injektion
Code-Injektion ist eine häufige Form von Injektionsangriffen. Angreifer nutzen ihr Wissen über Programmiersprachen, Frameworks, Datenbanken oder Betriebssysteme von Webanwendungen, um Code über Textfelder einzuschleusen und den Webserver zu manipulieren.
Solche Angriffe sind möglich, wenn Anwendungen Eingabedaten nicht ausreichend überprüfen. Wenn Benutzer beliebigen Text in Eingabefelder eingeben können, ist die Anwendung anfällig. Um dies zu verhindern, müssen Anwendungen die möglichen Eingaben einschränken.
Beispielsweise sollten Anwendungen die Datenmenge begrenzen, Datenformate vor Annahme prüfen und die zulässigen Zeichen einschränken.
Code-Injektionsschwachstellen lassen sich leicht durch Testen der Texteingabe mit verschiedenen Inhalten erkennen. Die Ausnutzung solcher Schwachstellen ist zwar nicht trivial, aber bei Erfolg kann sie zu einem Verlust von Vertraulichkeit, Integrität, Verfügbarkeit oder Funktionalität führen.
SQL-Injektion
Ähnlich der Code-Injektion wird hier ein SQL-Skript in ein Texteingabefeld eingefügt. Dieses Skript wird an die Anwendung gesendet und direkt in der Datenbank ausgeführt. Dadurch kann der Angreifer Anmeldebildschirme umgehen, vertrauliche Daten auslesen, ändern oder sogar zerstören oder Administratoroperationen in der Datenbank ausführen.
PHP- und ASP-Anwendungen sind aufgrund ihrer älteren Schnittstellen anfälliger für SQL-Injection-Angriffe, während J2EE- und ASP.Net-Anwendungen besser geschützt sind. Die potenziellen Auswirkungen eines SQL-Injection-Angriffs hängen von den Fähigkeiten und der Kreativität des Angreifers ab, was die Bedrohung sehr hoch macht.
Befehlsinjektion
Diese Angriffe basieren ebenfalls auf mangelnder Eingabevalidierung. Im Gegensatz zur Code-Injektion werden hier Systembefehle anstelle von Programmcode oder Skripten eingeschleust. Der Angreifer muss daher nicht die Programmiersprache der Anwendung oder die Sprache der Datenbank kennen, sondern das Betriebssystem des Hosting-Servers.
Die eingeschleusten Systembefehle werden mit den Rechten der Anwendung vom Host-Betriebssystem ausgeführt. Dies kann das Auslesen beliebiger Dateien, das Anzeigen der Verzeichnisstruktur und das Ändern von Benutzerpasswörtern ermöglichen.
Systemadministratoren können diese Angriffe verhindern, indem sie die Zugriffsberechtigungen von Webanwendungen auf einem Server einschränken.
Cross-Site-Scripting (XSS)
Wenn eine Anwendung Benutzereingaben ohne Validierung oder Kodierung in ihre Ausgabe einfügt, ermöglicht sie Angreifern, schädlichen Code an andere Benutzer zu senden. XSS-Angriffe nutzen diese Schwachstelle, um bösartige Skripte in vertrauenswürdige Websites einzuschleusen, die dann an andere Benutzer weitergeleitet werden.
Der Browser des Opfers führt das schädliche Skript aus, ohne es als schädlich zu erkennen. Dadurch kann auf Sitzungstoken, Cookies oder andere vertrauliche Informationen zugegriffen werden. Bei entsprechender Programmierung können Skripte sogar den Inhalt von HTML-Dateien manipulieren.
XSS-Angriffe werden in zwei Kategorien unterteilt: gespeichert und reflektiert.
Bei gespeicherten XSS-Angriffen befindet sich das schädliche Skript dauerhaft auf dem Zielserver, z.B. in einem Nachrichtenforum oder einer Datenbank. Das Opfer erhält es, wenn der Browser die gespeicherten Informationen abfragt. Bei reflektierten XSS-Angriffen wird das schädliche Skript in einer Antwort gespiegelt, die die Eingabe an den Server enthält. Dies kann beispielsweise eine Fehlermeldung oder ein Suchergebnis sein.
XPath-Injektion
Diese Art von Angriff entsteht, wenn eine Webanwendung Benutzerdaten verwendet, um eine XPath-Abfrage für XML-Daten zu erstellen. Die Funktionsweise ist ähnlich der SQL-Injektion: Angreifer senden falsche Daten, um die Struktur der XML-Daten zu ermitteln und dann auf diese zuzugreifen.
XPath ist eine Standardsprache, die wie SQL verwendet wird, um Attribute zu identifizieren. Webanwendungen verwenden Benutzereingaben, um ein Muster festzulegen, mit dem die Daten übereinstimmen sollen. Durch das Senden falscher Eingaben kann dieses Muster jedoch in eine Operation umgewandelt werden, die der Angreifer ausführen möchte.
Im Gegensatz zu SQL gibt es keine verschiedenen Versionen von XPath. Daher kann die XPath-Injektion unabhängig von der Implementierung in jeder Webanwendung mit XML-Daten durchgeführt werden. Dies bedeutet auch, dass der Angriff automatisiert und gegen viele Ziele eingesetzt werden kann.
Mail-Befehlsinjektion
Diese Angriffsmethode zielt auf E-Mail-Server und Anwendungen ab, die IMAP- oder SMTP-Anweisungen mit nicht validierten Benutzereingaben erstellen. IMAP- und SMTP-Server sind oft nicht so gut geschützt wie Webserver und sind daher möglicherweise anfälliger. Über einen Mailserver könnten Angreifer Einschränkungen wie Captchas oder limitierte Anfragen umgehen.
Um einen SMTP-Server anzugreifen, benötigen Angreifer ein gültiges E-Mail-Konto, um Nachrichten mit eingeschleusten Befehlen zu senden. Ist der Server anfällig, beantwortet er die Anfragen der Angreifer und ermöglicht ihnen z.B. Beschränkungen zu umgehen und den Server zum Versenden von Spam zu missbrauchen.
IMAP-Injektionen könnten hauptsächlich in Webmail-Anwendungen mit der Nachrichtenlesefunktion stattfinden. Der Angriff kann erfolgen, indem eine URL mit den eingeschleusten Befehlen in die Adressleiste eingegeben wird.
CRLF-Injektion
Das Einfügen von Wagenrücklauf- und Zeilenvorschubzeichen (CRLF) in Eingabefelder von Webformularen wird als CRLF-Injektion bezeichnet. Diese unsichtbaren Zeichen markieren in vielen Internetprotokollen wie HTTP, MIME oder NNTP das Ende einer Zeile oder eines Befehls.
Durch das Einfügen eines CRLF in eine HTTP-Anfrage, gefolgt von HTML-Code, könnten beispielsweise benutzerdefinierte Webseiten an Besucher gesendet werden.
Dieser Angriff kann auf Webanwendungen angewendet werden, die Benutzereingaben nicht richtig filtern. Diese Schwachstelle öffnet auch die Tür für andere Arten von Injektionsangriffen wie XSS und Code-Injektion, was im schlimmsten Fall zur Übernahme der Website führen kann.
Host-Header-Injektion
Auf Servern mit mehreren Websites oder Anwendungen ist der Host-Header wichtig, um zu bestimmen, welche der Anwendungen eine eingehende Anfrage bearbeitet. Der Wert des Headers teilt dem Server mit, an welchen virtuellen Host die Anfrage weitergeleitet werden soll. Erhält der Server einen ungültigen Host-Header, leitet er ihn normalerweise an den ersten virtuellen Host der Liste weiter. Dies ist eine Schwachstelle, die Angreifer ausnutzen können, um beliebige Host-Header an den ersten virtuellen Host zu senden.
Host-Header-Manipulationen sind oft mit PHP-Anwendungen verbunden, können aber auch in anderen Webentwicklungstechnologien auftreten. Host-Header-Angriffe bereiten den Weg für andere Angriffe, wie z.B. Web-Cache-Poisoning. Die Folgen könnten die Ausführung sensibler Operationen durch Angreifer sein, z.B. das Zurücksetzen von Passwörtern.
LDAP-Injektion
LDAP ist ein Protokoll zur Erleichterung der Suche nach Ressourcen in einem Netzwerk. Es ist nützlich in Intranets und kann als Teil eines Single-Sign-On-Systems verwendet werden. LDAP-Abfragen verwenden spezielle Steuerzeichen, die das Verhalten beeinflussen können. Angreifer können das Verhalten einer LDAP-Abfrage verändern, wenn sie Steuerzeichen einfügen.
Auch hier ist das Grundproblem die unzureichende Validierung der Benutzereingabe. Wird der Text eines Benutzers ohne Bereinigung als Teil einer LDAP-Abfrage verwendet, könnte die Abfrage beispielsweise eine Liste aller Benutzer an einen Angreifer ausgeben.
Injektionsangriffe verhindern
Injektionsangriffe richten sich an öffentlich zugängliche Server und Anwendungen. Die Verantwortung für die Verhinderung dieser Angriffe liegt bei Anwendungsentwicklern und Serveradministratoren.
Anwendungsentwickler müssen die Risiken fehlerhafter Eingabevalidierung kennen und Best Practices lernen, um Benutzereingaben zu bereinigen. Serveradministratoren müssen ihre Systeme regelmäßig auf Schwachstellen überprüfen und diese schnellstmöglich beheben. Es gibt viele Möglichkeiten für solche Audits, entweder bei Bedarf oder automatisiert.