Das Problem bei Webanwendungen besteht darin, dass sie offen Milliarden von Internetnutzern 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 einfach und grundlegend Brute-Force-. Bots führten diese Angriffe normalerweise durch - oder Personen mit viel Freizeit -, die zig Kombinationen von Benutzernamen und Passwörtern versuchten, bis sie einen fanden, der den Zugriff auf die Zielanwendung gewährte.
Brute-Force-Angriffe sind dank Kennwortrichtlinien, begrenzten Anmeldeversuchen und Captchas keine Bedrohung mehr. Aber Cyberkriminelle lieben es, neue Exploits zu entdecken und sie für neue Arten von Angriffen einzusetzen. Vor langer Zeit entdeckten sie, dass Textfelder auf Anwendungen oder Webseiten ausgenutzt werden können, indem unerwarteter Text eingegeben oder eingefügt wird, der die Anwendung dazu zwingt, etwas zu tun, was sie eigentlich nicht tun sollte. Auf diese Weise kamen die sogenannten Injektionsangriffe in die Szene.
Injection-Angriffe können nicht nur verwendet werden, um sich bei einer Anwendung anzumelden, ohne Benutzername und Kennwort zu kennen, sondern auch, um private, vertrauliche oder vertrauliche Informationen preiszugeben oder sogar um einen gesamten Server zu entführen. Deshalb sind diese Angriffe nicht nur eine Bedrohung für Webanwendungen, aber auch für die Benutzer, deren Daten sich in diesen Anwendungen befinden, und im schlimmsten Fall für andere verbundene Anwendungen und Dienste.
Code injection
Code-Injection ist eine der häufigsten Arten von Injection-Attacken. Wenn Angreifer die Programmiersprache, das Framework, die Datenbank oder das von einer Webanwendung verwendete Betriebssystem kennen, können sie Code über Texteingabefelder einfügen, um den Webserver zu zwingen, das zu tun, was sie wollen.
Diese Arten von Injektionsangriffen sind bei Anwendungen möglich, bei denen die Validierung der Eingabedaten fehlt. Wenn Benutzer in ein Texteingabefeld eingeben können, was sie möchten, kann die Anwendung möglicherweise ausgenutzt werden. Um diese Angriffe zu verhindern, muss die Anwendung die Eingabebenutzer so weit wie möglich einschränken.
Beispielsweise muss die Menge der erwarteten Daten begrenzt, das Datenformat vor dem Akzeptieren überprüft und der Satz zulässiger Zeichen eingeschränkt werden.
Die Sicherheitsanfälligkeiten bezüglich Codeinjektion können leicht gefunden werden, indem lediglich die Texteingabe einer Webanwendung mit verschiedenen Arten von Inhalten getestet wird. Wenn sie gefunden werden, sind die Sicherheitslücken nur mäßig auszunutzen. Wenn es einem Angreifer jedoch gelingt, eine dieser Sicherheitsanfälligkeiten auszunutzen, kann dies zu einem Verlust der Vertraulichkeit, Integrität, Verfügbarkeit oder Anwendungsfunktionalität führen.
SQL injection
Ähnlich wie bei der Code-Injection fügt dieser Angriff ein SQL-Skript - die Sprache, die von den meisten Datenbanken zum Ausführen von Abfragevorgängen verwendet wird - in ein Texteingabefeld ein. Das Skript wird an die Anwendung gesendet, die es direkt in ihrer Datenbank ausführt. Infolgedessen kann der Angreifer einen Anmeldebildschirm durchlaufen oder gefährlichere Dinge tun, z. B. vertrauliche Daten direkt aus der Datenbank lesen, Datenbankdaten ändern oder zerstören oder Verwaltungsvorgänge für die Datenbank ausführen.
PHP- und ASP-Anwendungen sind anfällig für SQL-Injection-Angriffe aufgrund seiner älteren funktionalen Schnittstellen. J2EE- und ASP.Net-Apps sind normalerweise besser vor diesen Angriffen geschützt. Wenn eine SQL-Injection-Schwachstelle gefunden wird - und diese leicht gefunden werden kann -, 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.
Command injection
Diese Angriffe sind auch möglich, hauptsächlich aufgrund unzureichender 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. Sie müssen jedoch das vom Hosting-Server verwendete Betriebssystem kennen.
Die eingefügten Systembefehle werden vom Host-Betriebssystem mit dem ausgeführt Berechtigungen der AnwendungDies könnte 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.
Diese Angriffe können von einem Systemadministrator verhindert werden, indem die Systemzugriffsebene der auf einem Server ausgeführten Webanwendungen eingeschränkt wird.
Cross-site scripting
Wenn eine Anwendung Eingaben eines Benutzers in die von ihr generierte Ausgabe einfügt, ohne sie zu validieren oder zu codieren, bietet sie einem Angreifer die Möglichkeit, bösartigen Code an einen anderen Endbenutzer zu senden. Cross-Site Scripting (XSS) -Angriffe nutzen diese Möglichkeiten, um schädliche Skripte in vertrauenswürdige Websites einzufügen, die letztendlich 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 lässt der Browser auf Sitzungstoken, Cookies oder vertrauliche Informationen zugreifen, die vom Browser gespeichert werden. Bei richtiger Programmierung könnten die Skripte sogar den Inhalt einer HTML-Datei neu schreiben.
XSS-Angriffe können im Allgemeinen in zwei verschiedene Kategorien unterteilt werden: gespeichert und reflektiert.
In gelagert Bei 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. Im reflektiert Bei XSS-Angriffen spiegelt sich das schädliche Skript in einer Antwort wider, die die an den Server gesendeten Eingaben enthält. Dies kann beispielsweise eine Fehlermeldung oder ein Suchergebnis sein.
XPath injection
Diese Art von Angriff ist möglich, wenn eine Webanwendung Informationen verwendet, die von einem Benutzer bereitgestellt wurden, um eine XPath-Abfrage für XML-Daten zu erstellen. Die Art und Weise, wie dieser Angriff funktioniert, ist ähnlich wie 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 mit SQL die Attribute angeben können, die Sie suchen möchten. Um eine Abfrage für 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 in 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-Injection gegen eine beliebige Anzahl von Zielen abgefeuert werden.
Mail command injection
Diese Angriffsmethode kann verwendet werden, um E-Mail-Server und Anwendungen auszunutzen, die IMAP erstellen oder SMTP -Anweisungen mit falsch validierten Benutzereingaben. Gelegentlich bieten IMAP- und SMTP-Server keinen starken Schutz gegen Angriffe, wie dies bei den meisten Webservern der Fall ist, und könnten daher besser ausnutzbar sein. Durch den Zugang über einen Mailserver könnten 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 injizierten Befehlen zu senden. Wenn der Server anfällig ist, reagiert er auf die Anforderungen der Angreifer und ermöglicht ihnen beispielsweise, Servereinschränkungen zu überschreiben und ihre Dienste zum Senden von Spam zu verwenden.
Die IMAP-Injektion kann hauptsächlich in Webmail-Anwendungen erfolgen, wobei die Funktionen zum Lesen von Nachrichten genutzt werden. In diesen Fällen kann der Angriff ausgeführt werden, indem einfach in die Adressleiste eines Webbrowsers eine URL mit den eingefügten Befehlen eingegeben wird.
CRLF injection
Das Einfügen von Wagenrücklauf- und Zeilenvorschubzeichen - Kombination als CRLF bezeichnet - in Webformular-Eingabefelder stellt eine Angriffsmethode dar, die als CRLF-Injektion bezeichnet wird. Diese unsichtbaren Zeichen geben das Ende einer Zeile oder das Ende eines Befehls in vielen herkömmlichen Internetprotokollen wie HTTP, MIME oder NNTP an.
Beispielsweise kann das Einfügen einer CRLF in eine HTTP-Anforderung, gefolgt von einem bestimmten HTML-Code, benutzerdefinierte Webseiten an die Besucher einer Website senden.
Dieser Angriff kann auf anfälligen Webanwendungen ausgeführt werden, bei denen die Benutzereingaben nicht ordnungsgemäß gefiltert werden. Diese Sicherheitsanfälligkeit öffnet die Tür für andere Arten von Injection-Angriffen wie XSS und Code-Injection und kann auch auf eine entführte Website zurückzuführen sein.
Host Header injection
Auf Servern, auf denen viele Websites oder Webanwendungen gehostet werden, muss anhand des Host-Headers festgelegt werden, welche der residenten Websites oder Webanwendungen - jede davon als virtueller Host bezeichnet - eine eingehende Anforderung verarbeiten soll. Der Wert des Headers teilt dem Server mit, an welchen der virtuellen Hosts eine Anforderung gesendet werden soll. Wenn der Server einen ungültigen Host-Header empfängt, übergibt er diesen normalerweise an den ersten virtuellen Host in der Liste. Dies stellt eine Sicherheitsanfälligkeit dar, mit der Angreifer beliebige Host-Header an den ersten virtuellen Host auf einem Server senden können.
Die Manipulation des Host-Headers hängt häufig mit PHP-Anwendungen zusammen, kann jedoch auch mit anderen Webentwicklungstechnologien durchgeführt werden. Host-Header-Angriffe fungieren als Enabler für andere Arten von Angriffen, z. B. Web-Cache-Vergiftungen. Zu den Konsequenzen könnte die Ausführung sensibler Vorgänge durch die Angreifer gehören, z. B. das Zurücksetzen von Kennwörtern.
LDAP injection
LDAP ist ein Protokoll, das die Suche nach Ressourcen (Geräten, Dateien, anderen Benutzern) in einem Netzwerk erleichtert. Es ist sehr nützlich für Intranets und kann als Teil eines Single-Sign-On-Systems zum Speichern von Benutzernamen und Kennwörtern verwendet werden. Bei LDAP-Abfragen werden spezielle Steuerzeichen verwendet, die sich auf die Steuerung auswirken. Angreifer können möglicherweise das beabsichtigte Verhalten einer LDAP-Abfrage ändern, wenn sie Steuerzeichen einfügen können.
Wiederum ist das Hauptproblem, das LDAP-Injektionsangriffe ermöglicht, eine falsch validierte Benutzereingabe. Wenn der Text, den ein Benutzer an eine Anwendung sendet, als Teil einer LDAP-Abfrage verwendet wird, ohne ihn zu bereinigen, kann die Abfrage eine Liste aller Benutzer abrufen und sie einem Angreifer anzeigen, indem nur ein Sternchen (*) rechts verwendet wird innerhalb einer Eingabezeichenfolge platzieren.
Verhinderung von Injektionsangriffen
Wie wir in diesem Artikel gesehen haben, richten sich alle Injection-Angriffe gegen Server und Anwendungen mit offenem Zugriff auf jeden Internetbenutzer. Die Verantwortung zur Verhinderung dieser Angriffe liegt bei Anwendungsentwicklern und Serveradministratoren.
Anwendungsentwickler müssen die Risiken kennen, die mit der falschen Validierung von Benutzereingaben verbunden sind, und Best Practices erlernen, um Benutzereingaben zu Zwecken der Risikoprävention zu bereinigen. Serveradministratoren müssen ihre Systeme regelmäßig überprüfen Schwachstellen erkennen und korrigieren Sie sie so schnell wie möglich. Es gibt viele Möglichkeiten, diese Audits entweder bei Bedarf oder automatisch durchzuführen.
