Bei einer Injection Attack kann ein Angreifer einer Webanwendung bösartige Eingaben zuführen (injizieren) und den Betrieb der Anwendung ändern, indem er sie zwingt, bestimmte Befehle auszuführen.
Eine Injection Attack kann Daten preisgeben oder beschädigen, zu einer Beeinträchtigung des Dienstes oder einer vollständigen Kompromittierung des Webservers führen. Solche Angriffe sind aufgrund von Schwachstellen im Code einer Anwendung möglich, die nicht validierte Benutzereingaben zulassen.
Injection-Angriffe gehören zu den häufigsten und gefährlichsten Web-Angriffen. Diese Schwachstellen stehen auf Platz 1 der OWASP Top Ten Web Application Security Risks. Mehrere Injection Attacks sind auch in der Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses aufgeführt.
Unsere Scans zeigen immer wieder, dass Websites für diese Art von Angriffen anfällig sind und das manchmal sogar in kritischem Maße. Viele Injection Angriffe können Ihre Webanwendungen schädigen und schwere Datenverluste oder -schäden verursachen.
Hier sind die häufigsten und schwerwiegendsten Arten von Injektionsangriffen, für die Ihre Anwendung anfällig sein kann.
Arten von Injection Attacks
SQL und Cross-Site Scripting Injection Attacks sind zwar die gängigsten, aber es gibt eine Vielzahl solcher Angriffe, die alle unterschiedliche Absichten und Mittel haben, um sie zu erreichen.
Die wichtigsten Arten von Injection Attacks, für die Ihre Anwendung anfällig sein kann, sind:
SQL Injection (SQLi)
SQL ist eine Abfragesprache für die Kommunikation mit einer Datenbank. Sie kann verwendet werden, um Aktionen zum Abrufen, Löschen und Speichern von Daten in der Datenbank durchzuführen.
Ein Angreifer wird versuchen, die in der Webanwendung verwendete SQL-Abfrage zu manipulieren und bei einem SQL-Injection-Angriff (SQLi) direkten Zugriff auf Ihre Daten zu erlangen. Dies geschieht in der Regel über ein Eingabefeld eines Webformulars, über Kommentarfelder oder andere für den Benutzer frei zugängliche Möglichkeiten.
Solche bösartigen SQL-Anweisungen versuchen, eine Schwachstelle in den Authentifizierungs- und Autorisierungsverfahren der Anwendung auszunutzen. Wenn sie erfolgreich sind, führt die SQL-Datenbank die Befehle aus, die der Angreifer injiziert hat.
Je nach Art der SQL Injection können sie Daten aus der Datenbank lesen, ändern, hinzufügen oder löschen.
Cross-Site Scripting (XSS)
Wann immer eine Anwendung Benutzereingaben innerhalb der von ihr erzeugten Ausgabe zulässt, kann ein Angreifer bösartigen Code an einen anderen Endbenutzer senden, ohne ihn zu validieren oder zu kodieren. Cross-Site Scripting (XSS) Angriffe nutzen diese Gelegenheit, um bösartige Skripte in vertrauenswürdige Websites einzuschleusen.
Bei einem Cross-Site-Scripting-Angriff wird ein Text mit bösartigem Code (normalerweise in JavaScript) in eine Webseite eingefügt. Wenn ein ahnungsloser Nutzer diese Webseite besucht, wird der Code ausgeführt.
So kann beispielsweise eine Textzeichenfolge in die URL eingefügt werden. Wenn die Anwendung den Code nicht validiert und ihn durchlässt, führt der Browser des Benutzers den Code aus, was zu einem Einbruch führt.
Ein XSS-Angriff kann verwendet werden, um Cookie-Details zu stehlen, Benutzereinstellungen zu ändern, Benutzersitzungen zu unterwandern und vieles mehr. Dies kann die Tür zu Impersonation und Defacement öffnen.
Code Injection
In diesem Szenario ist ein Angreifer mit dem Anwendungscode und der Programmiersprache vertraut. Unter Ausnutzung einer Schwachstelle kann er versuchen, Code in die Anwendung einzuschleusen, der von ihrem Webserver als Befehl ausgeführt wird. Dies unterscheidet sich von einer Command Injection durch das Betriebssystem (siehe unten).
Der Code wird in der Regel über mehrere Eingabefelder, einschließlich Texteingaben, HTTP GET/POST/PUT/DELETE-Parameter, Header, Cookies usw., eingeschleust.
Sobald der Angreifer in die Zielanwendung eingedrungen ist, kann er den Webserver dazu zwingen, das Gewünschte zu tun, indem er sich größere Rechte verschafft.
Eine Code Injection kann sich überall auf eine Anwendung auswirken, von dem Zugriff auf Daten bis hin zur vollständigen Kompromittierung des Systems. Daher ist eine Schwachstelle für eine Code-Injektion von großer Bedeutung.
Command Injection
Manchmal müssen Webanwendungen einen Systembefehl auf dem Webserver abrufen, auf dem sie ausgeführt werden. Wenn in solchen Fällen die Benutzereingabe nicht validiert und eingeschränkt wird, kann es zu einer Command Injection kommen.
Im Gegensatz zu Code Injections muss der Angreifer bei Command Injections nur das verwendete Betriebssystem kennen. Dann fügt der Angreifer einen Befehl in das System ein, wobei er die Benutzerrechte nutzt. Der eingefügte Befehl wird dann auf dem Host-System ausgeführt.
Eine Command Injection kann diese Anwendung und ihre Daten sowie das gesamte System, angeschlossene Server, Systeme und andere Infrastrukturen gefährden.
CCS Injection
Eine CCS Injektion nutzt eine Schwachstelle aus, die bei der ChangeCipherSpec-Verarbeitung in einigen Versionen von OpenSSL gefunden wurde.
Bei einem solchen Eingriff werden von Angreifern ungültige Signale in der Handshake-Sitzung zwischen Servern und Clients gesendet. Dadurch können sie Material mithilfe von encryption keys erbeuten, auf die Kommunikation zwischen Server und Client zugreifen und möglicherweise Identitätsdiebstahl begehen.
Dies sind die häufigsten und schwerwiegendsten Injection Attacks auf Webanwendungen. Leider kann der Schutz Ihrer Anwendungen für Unternehmen oder Einzelpersonen mit vielen Webanwendungen und geringer Entwickler-Zeit und begrenzter -Ressourcen eine große Herausforderung darstellen.
Um Ihre Anwendung auf SQL-Injections, Cross-Site Scripting (XSS) und andere OWASP Top 10 Schwachstellen zu testen, probieren Sie unsere kostenlose Testversion aus und starten Sie Ihren ersten Scan in wenigen Minuten.
Andere häufig auftretende Formen von Injection Attacks
SMTP/IMAP Command Injection
Neben den oben genannten gibt es noch einige andere Arten von Injection Attacks, die ebenfalls verwendet werden. Leider werden diese derzeit nicht von der Crashtest Security Suite abgedeckt.
Auch als E-Mail Header Injection bekannt, ist dies eine Form der Mail Command Injection, die auf Mailserver abzielt. Dies geschieht durch das Einfügen zusätzlicher Header in eine Nachricht, die Befehle an den SMTP-Server enthält. Leider verfügen die meisten Mailserver nicht über einen starken Schutz gegen Angriffe auf IMAP und SMTP.
Host Header injection
Wenn ein Server viele Websites verwaltet, benötigt er schließlich einen Host Header. Der Wert des Host Headers gibt an, welche Website oder Webanwendung auf eine HTTP-Anfrage antworten muss. Die Manipulation eines solchen Host Headers stellt eine Form des Angriffs dar, die zum Zurücksetzen von Passwörtern führen kann. Darüber hinaus können Host Header Injections auch zu Web-Cache-Poisoning führen.
LDAP Injection
Das Lightweight Directory Access Protocol (LDAP) ist für die Suche nach Ressourcen (Geräte, Dateien, andere Benutzer) in einem Netzwerk konzipiert. Es ist vorteilhaft für Intranets und, wenn es als Teil eines Single-Sign-On-Systems verwendet wird, kann es Benutzernamen und Passwörter speichern. Bei einem solchen Angriff wird eine nicht validierte LDAP-Anweisung injiziert, die einen Server anweist, einen bestimmten Befehl auszuführen.
CRLF Injection
„Carriage Return“ und „Line Feed“ (CRLF), oder \r und \n, sind Elemente, die in HTTP-Headern verwendet werden, um eine Zeile zu beenden. Darüber hinaus werden sie verwendet, um Textstreams, wie z. B. HTTP-Header, in einzelne Elemente aufzuteilen. Eine CRLF Injection liegt vor, wenn es einem Angreifer gelingt, eine CRLF-Sequenz in eine Anwendung einzuschleusen. In der Regel geschieht dies durch Einfügen in einen HTTP-Header, was dann als HTTP Response Splitting bezeichnet wird.
Wie lassen sich Injections Vulnerabilities in Ihrer Webanwendung erkennen?
Der einfachste Weg, eine Injection Vulnerability zu erkennen, ist die Verwendung eines automatisierten Web Vulnerability Scanners. Ein solcher Scanner, der einem automatisierten Pentest-Tool ähnelt, kann Angriffsvektoren leicht erkennen und Ihnen dabei helfen, die notwendigen Schritte zum Schutz Ihrer Anwendung zu unternehmen.
Da Sie nun die häufigsten Schwachstellen von Webanwendungen kennen, sollten Sie die Grundlagen abdecken und diese häufigen Injection Attacks in Ihrem Entwicklungsprozess berücksichtigen. Und wenn Sie sich nicht sicher sind, wie genau Sie eine großartige Schwachstellenanalyse durchführen können, haben wir für Sie die Lösung.
Crashtest Security erkennt, bewertet und behebt die meisten Injektionsschwachstellen. Führen Sie hier kostenlos einen vollständigen Scan durch und bewerten Sie Schwachstellen wie SQL-Injection und Cross-Site Scripting (XSS).
Wie kann man Injection Attacks verhindern?
Um Injection Attacks auf Ihre Webanwendung zu verhindern, müssen Sie diese sicher codieren. OWASP hat mehrere Möglichkeiten zur Verhinderung von SQL-Injektionsangriffen definiert, die jedoch auch für andere Arten von Datenbankzugriffen gelten. Zu diesen und weiteren Strategien gehören:
- Validierung von Benutzereingaben durch Erstellung einer Erlaubnisliste (Whitelist) für gültige Anweisungen und Konfiguration von Eingaben für Benutzerdaten nach Kontext
- Verwendung von vorbereiteten Anweisungen mithilfe von parametrisierten Abfragen, die helfen, zwischen Code und Benutzereingaben zu unterscheiden und Anweisungen nicht mit Befehlen zu verwechseln
- Verwendung von gespeicherten Abläufen, die in der Datenbank definiert und gespeichert sind und von der Webanwendung aus aufgerufen werden
- Begrenzung von Sonderzeichen, um die Verkettung von Zeichenfolgen zu verhindern
- Umgehung aller Benutzereingaben (laut OWASP der letzte Ausweg)
- Verringern der Angriffsfläche Ihrer Anwendung durch Entfernen aller unnötigen Funktionen, die ansonsten geschützt werden müssten
- Durchsetzung des Prinzips der geringsten Berechtigung und des strikten Zugriffs, indem nur die für ein Konto erforderlichen Berechtigungen zugelassen werden
