Das Problem bei Webanwendungen besteht darin, dass sie Milliarden von Internetnutzern offen ausgesetzt sind, von denen viele ihre Sicherheitsmaßnahmen brechen wollen – aus welchen Gründen auch immer.
In den frühen Tagen des Internets war eine der häufigsten Angriffsmethoden einfache, einfache Brute-Force-Angriffe. Üblicherweise führten Bots diese Angriffe durch – oder Personen mit viel Freizeit – die zigtausend 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, begrenzten Anmeldeversuchen und Captchas keine Bedrohung mehr. Aber Cyberkriminelle lieben es, neue Exploits zu entdecken und sie zu verwenden, um neue Arten von Angriffen durchzuführen. Vor langer Zeit entdeckten sie, dass Textfelder auf Anwendungen oder Webseiten ausgenutzt werden konnten, indem unerwarteter Text in sie eingegeben – oder injiziert – wurde, der die Anwendung dazu zwingen würde, etwas zu tun, was sie nicht tun sollte. Auf diese Weise kamen die sogenannten Injektionsangriffe auf den Plan.
Injection-Angriffe können nicht nur verwendet werden, um sich bei einer Anwendung anzumelden, ohne Benutzernamen und Passwort zu kennen, sondern auch, um private, vertrauliche oder sensible Informationen offenzulegen oder sogar einen ganzen Server zu kapern. Aus diesem Grund sind diese Angriffe nicht nur eine Bedrohung für Webanwendungen, sondern auch für die Benutzer, deren Daten sich in diesen Anwendungen befinden, und im schlimmsten Fall für andere verbundene Anwendungen und Dienste.
Inhaltsverzeichnis
Code-Injektion
Code-Injection ist eine der häufigsten Arten von Injection-Angriffen. Wenn Angreifer die Programmiersprache, das Framework, die Datenbank oder das Betriebssystem einer Webanwendung kennen, können sie Code über Texteingabefelder einschleusen, um den Webserver zu zwingen, das zu tun, was sie wollen.
Diese Arten von Injection-Angriffen sind bei Anwendungen möglich, denen die Überprüfung der Eingabedaten fehlt. Wenn Benutzer in ein Texteingabefeld eingeben können, was sie wollen, ist die Anwendung potenziell ausnutzbar. Um diese Angriffe zu verhindern, muss die Anwendung die Eingaben, die Benutzer eingeben dürfen, so weit wie möglich einschränken.
Beispielsweise muss es die Menge der erwarteten Daten begrenzen, das Datenformat prüfen, bevor es akzeptiert wird, und den Satz zulässiger Zeichen einschränken.
Die Code-Injection-Schwachstellen lassen sich leicht finden, indem man einfach die Texteingabe einer Webanwendung mit verschiedenen Arten von Inhalten testet. 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 Anwendungsfunktionalität führen.
SQL-Injektion
Ähnlich wie bei der Code-Injektion fügt dieser Angriff ein SQL-Skript – die Sprache, die von den meisten Datenbanken zur Durchführung von Abfragevorgängen verwendet wird – in ein Texteingabefeld ein. Das Skript wird an die Anwendung gesendet, die es direkt auf ihrer Datenbank ausführt. Infolgedessen könnte der Angreifer einen Anmeldebildschirm passieren oder gefährlichere Dinge tun, wie z. B. vertrauliche Daten direkt aus der Datenbank lesen, Datenbankdaten ändern oder zerstören oder Administratoroperationen für die Datenbank ausführen.
PHP- und ASP-Anwendungen sind aufgrund ihrer älteren funktionalen Schnittstellen anfällig für SQL-Injection-Angriffe. J2EE- und ASP.Net-Apps sind normalerweise besser gegen diese Angriffe geschützt. Wenn eine SQL-Injection-Schwachstelle gefunden wird – und sie könnte leicht gefunden werden – wird das Ausmaß der potenziellen Angriffe nur durch die Fähigkeiten und die Vorstellungskraft des Angreifers begrenzt. Daher ist die Auswirkung eines SQL-Injection-Angriffs zweifellos hoch.
Injektion befehlen
Diese Angriffe sind ebenfalls möglich, hauptsächlich aufgrund unzureichender Eingabevalidierung. Sie unterscheiden sich von Code-Injection-Angriffen dadurch, dass der Angreifer anstelle von Programmcode oder Skripten Systembefehle einfügt. Daher muss der Hacker weder die Programmiersprache kennen, auf der die Anwendung basiert, noch die von der Datenbank verwendete Sprache. Sie müssen jedoch das vom Hosting-Server verwendete Betriebssystem kennen.
Die eingefügten Systembefehle werden vom Host-Betriebssystem mit den Privilegien der Anwendung ausgeführt, was unter anderem das Offenlegen des Inhalts beliebiger Dateien auf dem Server, das Anzeigen der Verzeichnisstruktur eines Servers und das Ändern von Benutzerkennwörtern ermöglichen könnte .
Diese Angriffe können von einem Systemadministrator verhindert werden, indem er die Systemzugriffsebene der auf einem Server ausgeführten Webanwendungen einschränkt.
Cross-Site-Scripting
Immer wenn eine Anwendung Eingaben eines Benutzers in die von ihr generierte Ausgabe einfügt, ohne sie zu validieren oder zu codieren, gibt sie einem Angreifer die Möglichkeit, bösartigen Code an einen anderen Endbenutzer zu senden. Cross-Site-Scripting-Angriffe (XSS) nutzen diese Gelegenheiten, um bösartige Skripts in vertrauenswürdige Websites einzuschleusen, die schließlich an andere Benutzer der Anwendung gesendet werden, die Opfer des Angreifers werden.
Der Browser des Opfers führt das schädliche Skript aus, ohne zu wissen, dass es nicht vertrauenswürdig ist. Daher ermöglicht der Browser den Zugriff auf Sitzungstoken, Cookies oder vertrauliche Informationen, die vom Browser gespeichert werden. Bei richtiger Programmierung könnten die Skripte sogar den Inhalt einer HTML-Datei umschreiben.
XSS-Angriffe können allgemein in zwei verschiedene Kategorien eingeteilt werden: gespeichert und reflektiert.
Bei gespeicherten XSS-Angriffen befindet sich das schädliche 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 spiegelt sich das schädliche Skript in einer Antwort wider, die die an den Server gesendete Eingabe enthält. Dies kann beispielsweise eine Fehlermeldung oder ein Suchergebnis sein.
XPath-Injektion
Diese Art von Angriff ist möglich, wenn eine Webanwendung Informationen verwendet, die von einem Benutzer bereitgestellt werden, um eine XPath-Abfrage für XML-Daten zu erstellen. Die Funktionsweise dieser Angriffe ähnelt der SQL-Injection: Angreifer senden fehlerhafte 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 SQL die Attribute angeben können, die Sie finden möchten. Um eine Abfrage von XML-Daten durchzuführen, verwenden Webanwendungen Benutzereingaben, um ein Muster festzulegen, mit dem die Daten übereinstimmen sollen. Durch das Senden fehlerhafter Eingaben kann das Muster zu einer Operation werden, die der Angreifer auf die Daten anwenden möchte.
Anders als bei SQL gibt es bei XPath keine unterschiedlichen Versionen. Dies bedeutet, dass die XPath-Injektion unabhängig von der Implementierung in jeder Webanwendung durchgeführt werden kann, die XML-Daten verwendet. Das bedeutet auch, dass der Angriff automatisiert werden kann; Daher kann es im Gegensatz zur SQL-Injektion gegen 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 sind IMAP- und SMTP-Server nicht stark gegen Angriffe geschützt, wie dies bei den meisten Webservern der Fall wäre, und könnten daher besser angreifbar sein. Über einen Mailserver konnten Angreifer Beschrä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 senden. Wenn der Server anfällig ist, antwortet er auf die Anfragen der Angreifer und ermöglicht ihnen beispielsweise, Serverbeschränkungen zu umgehen und seine Dienste zum Versenden von Spam zu verwenden.
Die IMAP-Einschleusung könnte hauptsächlich in Webmail-Anwendungen erfolgen, wobei die Nachrichtenlesefunktion ausgenutzt wird. In diesen Fällen kann der Angriff durchgeführt werden, indem einfach in die Adressleiste eines Webbrowsers eine URL mit den eingeschleusten Befehlen eingegeben wird.
CRLF-Injektion
Das Einfügen von Wagenrücklauf- und Zeilenvorschubzeichen – eine Kombination, die als CRLF bekannt ist – in Webformular-Eingabefelder stellt eine Angriffsmethode dar, die als CRLF-Injektion bezeichnet wird. Diese unsichtbaren Zeichen zeigen in vielen herkömmlichen Internetprotokollen wie HTTP, MIME oder NNTP das Ende einer Zeile oder eines Befehls an.
Beispielsweise könnte das Einfügen eines CRLF in eine HTTP-Anforderung, gefolgt von einem bestimmten HTML-Code, benutzerdefinierte Webseiten an die Besucher einer Website senden.
Dieser Angriff kann auf anfällige Webanwendungen ausgeführt werden, die die Benutzereingaben nicht richtig filtern. Diese Schwachstelle öffnet die Tür für andere Arten von Injection-Angriffen, wie XSS und Code-Injection, und könnte auch dazu führen, dass eine Website gekapert wird.
Host-Header-Injektion
Auf Servern, die viele Websites oder Webanwendungen hosten, wird der Host-Header erforderlich, um zu bestimmen, welche der residenten Websites oder Webanwendungen – jede von ihnen 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 empfängt, leitet er ihn normalerweise an den ersten virtuellen Host in der Liste weiter. Dies stellt eine Schwachstelle dar, die Angreifer ausnutzen können, um beliebige Host-Header an den ersten virtuellen Host in einem Server zu senden.
Die Manipulation des Host-Headers ist häufig mit PHP-Anwendungen verbunden, kann aber auch mit anderen Webentwicklungstechnologien durchgeführt werden. Host-Header-Angriffe dienen als Wegbereiter für andere Arten von Angriffen, wie z. B. Web-Cache-Poisoning. Die Folgen könnten die Ausführung sensibler Operationen durch die Angreifer sein, beispielsweise das Zurücksetzen von Passwörtern.
LDAP-Injektion
LDAP ist ein Protokoll, das entwickelt wurde, um die Suche nach Ressourcen (Geräte, Dateien, andere Benutzer) in einem Netzwerk zu erleichtern. Es ist sehr nützlich für Intranets, und wenn es als Teil eines Single-Sign-On-Systems verwendet wird, kann es zum Speichern von Benutzernamen und Passwörtern verwendet werden. LDAP-Abfragen beinhalten die Verwendung spezieller Steuerzeichen, die sich auf die Steuerung auswirken. Angreifer können möglicherweise das beabsichtigte Verhalten einer LDAP-Abfrage ändern, wenn sie Steuerzeichen darin einfügen können.
Auch hier ist das Grundproblem, das LDAP-Injection-Angriffe ermöglicht, eine unsachgemäß 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 dazu führen, dass eine Liste aller Benutzer abgerufen und einem Angreifer angezeigt wird, nur indem ein Sternchen verwendet wird
an der richtigen Stelle innerhalb einer Eingabezeichenfolge.
Injektionsangriffe verhindern
Wie wir in diesem Artikel gesehen haben, richten sich alle Injection-Angriffe gegen Server und Anwendungen mit offenem Zugriff für alle Internetnutzer. Die Verantwortung, diese Angriffe zu verhindern, wird zwischen Anwendungsentwicklern und Serveradministratoren verteilt.
Anwendungsentwickler müssen die Risiken kennen, die mit der falschen Validierung von Benutzereingaben verbunden sind, und Best Practices lernen, um Benutzereingaben mit Risikopräventionszwecken zu bereinigen. Serveradministratoren müssen ihre Systeme regelmäßig überprüfen, um Schwachstellen zu erkennen und diese so schnell wie möglich zu beheben. Es gibt viele Möglichkeiten, diese Audits durchzuführen, entweder bei Bedarf oder automatisch.