8.8 CVE-2023-20182

Bei diesem Angriffsmuster wird ein Pufferüberlauf durch Manipulation von Umgebungsvariablen verursacht. Sobald der Angreifer herausfindet, dass er eine Umgebungsvariable ändern kann, kann er versuchen, die zugehörigen Puffer zum Überlaufen zu bringen. Dieser Angriff macht sich das implizite Vertrauen zunutze, das häufig in Umgebungsvariablen gesetzt wird. [Zielanwendung identifizieren] Der Angreifer identifiziert eine Zielanwendung oder ein Zielprogramm, um den Pufferüberlauf durchzuführen. Bei diesem Angriff sucht der Angreifer nach einer Anwendung, die den Inhalt einer Umgebungsvariablen in einen Puffer lädt. [Finde Injektionsvektor] Der Angreifer identifiziert einen Injektionsvektor, um den übermäßigen Inhalt in den Puffer der Zielanwendung zu übertragen. [Craft overflow content] Der Angreifer stellt den zu injizierenden Inhalt her. Wenn die Absicht darin besteht, die Software einfach zum Absturz zu bringen, muss der Inhalt nur aus einer übermäßigen Menge an Zufallsdaten bestehen. Wenn die Absicht darin besteht, den Überlauf zur Ausführung von beliebigem Code zu nutzen, stellt der Angreifer die Nutzlast so her, dass die überschriebene Rücksprungadresse durch eine Adresse seiner Wahl ersetzt wird. [Überlauf des Puffers] Mit Hilfe des Injektionsvektors injiziert der Angreifer den manipulierten Überlaufinhalt in den Puffer.

Ein Angreifer kann mit Server Side Include (SSI) Injection Code an eine Webanwendung senden, der dann vom Webserver ausgeführt wird. Auf diese Weise kann der Angreifer ähnliche Ergebnisse wie beim Cross-Site-Scripting erzielen, nämlich die Ausführung von beliebigem Code und die Offenlegung von Informationen, wenn auch in begrenzterem Umfang, da die SSI-Direktiven bei weitem nicht so mächtig sind wie eine vollwertige Skriptsprache. Dennoch kann sich der Angreifer bequem Zugang zu sensiblen Dateien, wie z. B. Passwortdateien, verschaffen und Shell-Befehle ausführen. [Anwendbarkeit bestimmen] Der Angreifer stellt fest, ob serverseitige Includes auf dem Ziel-Webserver aktiviert sind. [Injektionspunkt finden] Er sucht nach vom Benutzer kontrollierbaren Eingaben, einschließlich HTTP-Headern, die serverseitige Include-Direktiven an den Webserver weiterleiten können. [SSI einschleusen] Über den gefundenen Einschleusungspunkt sendet der Angreifer beliebigen Code, der von der Anwendung auf der Serverseite eingeschlossen wird. Er muss dann möglicherweise eine bestimmte Seite aufrufen, damit der Server die Include-Anweisung ausführt und einen Befehl ausführt oder eine Datei im Namen des Angreifers öffnet.

Ein Angreifer kann ein Opfer dazu bringen, Inhalte in seinen Webbrowser zu laden, die die Sicherheitszonenkontrollen umgehen, und sich Zugang zu erweiterten Privilegien verschaffen, um Skriptcode oder andere Webobjekte wie unsignierte ActiveX-Steuerelemente oder Applets auszuführen. Es handelt sich um einen Angriff zur Erhöhung der Berechtigungen, der auf die zonenbasierte Webbrowser-Sicherheit abzielt. [Suche nach Systemen, die für den Angriff anfällig sind] Suche nach Systemen, die Funktionen enthalten, auf die sowohl aus der Internetzone als auch aus der lokalen Zone zugegriffen wird. Es muss eine Möglichkeit geben, Eingaben in diese Funktionalität von der Internetzone aus vorzunehmen, und diese ursprüngliche Eingabe muss später auf einer Seite aus einer lokalen Zone verwendet werden. [Der Angreifer muss zunächst eine Systemfunktionalität oder möglicherweise eine andere Schwachstelle im System (z. B. Anfälligkeit für Cross-Site-Scripting) finden, die dem Angreifer einen Mechanismus bietet, um die Nutzlast (d. h. den auszuführenden Code) an den Benutzer zu liefern. Der Ort, von dem aus dieser Code im Browser des Benutzers ausgeführt wird, muss sich innerhalb der Zone des lokalen Rechners befinden. [Entwickeln Sie die Nutzlast, die in der höher privilegierten Zone im Browser des Benutzers ausgeführt werden soll. Injizieren Sie die Nutzlast und versuchen Sie, das Opfer (wenn möglich) dazu zu verleiten, die Funktionalität auszuführen, die die Nutzlast freisetzt.

Ein Angreifer verwendet Standard-SQL-Injection-Methoden, um Daten zur Ausführung in die Befehlszeile zu injizieren. Dies kann direkt durch den Missbrauch von Direktiven wie MSSQL_xp_cmdshell oder indirekt durch die Einspeisung von Daten in die Datenbank geschehen, die als Shell-Befehle interpretiert werden. Irgendwann später holt eine skrupellose Backend-Anwendung (oder könnte Teil der Funktionalität derselben Anwendung sein) die injizierten, in der Datenbank gespeicherten Daten ab und verwendet diese Daten als Befehlszeilenargumente, ohne eine ordnungsgemäße Validierung durchzuführen. Die bösartigen Daten entkommen dieser Datenebene, indem sie neue Befehle erzeugen, die auf dem Host ausgeführt werden. [Der Angreifer injiziert SQL-Syntax in benutzerkontrollierbare Dateneingaben, um die ungefilterte Ausführung der SQL-Syntax in einer Abfrage zu suchen. [Der Angreifer nutzt einen SQL-Injection-Angriff aus, um Shell-Code zu injizieren, der unter Ausnutzung der xp_cmdshell-Direktive ausgeführt werden soll. [Einschleusen bösartiger Daten in die Datenbank] Der Angreifer nutzt SQL-Injection, um Daten in die Datenbank einzuschleusen, die später zur Befehlsinjektion verwendet werden können, wenn sie als Befehlszeilenargument verwendet werden [Auslösen der Befehlszeilenausführung mit eingeschleusten Argumenten] Der Angreifer veranlasst die Ausführung von Befehlszeilenfunktionen, die zuvor eingeschleuste Datenbankinhalte als Argumente nutzen.

Ein Angreifer nutzt eine Schwäche im Code der Datenbankzugriffsschicht, der mit einem ORM-Tool (Object Relational Mapping) generiert wurde, oder eine Schwäche in der Art und Weise, wie ein Entwickler ein Persistenz-Framework verwendet hat, um eigene SQL-Befehle zu injizieren, die gegen die zugrunde liegende Datenbank ausgeführt werden. Der Angriff hier ähnelt der einfachen SQL-Injektion, mit dem Unterschied, dass die Anwendung nicht JDBC verwendet, um direkt mit der Datenbank zu kommunizieren, sondern eine Datenzugriffsschicht nutzt, die von einem ORM-Tool oder -Framework (z. B. Hibernate) generiert wurde. Obwohl der von einem ORM-Tool generierte Code in den meisten Fällen sichere Zugriffsmethoden enthält, die gegen SQL-Injektion immun sind, ist eine SQL-Injektion manchmal dennoch möglich, entweder aufgrund einer Schwäche im generierten Code oder aufgrund der Tatsache, dass der Entwickler die generierten Zugriffsmethoden nicht richtig verwendet hat. [Verwendetes Persistenz-Framework ermitteln] Ein Angreifer versucht herauszufinden, welches Persistenz-Framework von der Anwendung verwendet wird, um eine Schwäche im generierten Code der Datenzugriffsschicht oder eine Schwäche in der Art und Weise, wie die Datenzugriffsschicht möglicherweise vom Entwickler verwendet wurde, auszunutzen. [Auf ORM-Injection-Schwachstellen testen] Der Angreifer injiziert ORM-Syntax in vom Benutzer kontrollierbare Dateneingaben der Anwendung, um festzustellen, ob es möglich ist, die Struktur und den Inhalt von Datenabfragen zu ändern. SQL Injection über die generierte Datenzugriffsschicht durchführen] Ein Angreifer nutzt eine Schwachstelle in den generierten Datenzugriffsmethoden aus, die die Kontrollebene nicht ordnungsgemäß vom Datenplan trennt, oder möglicherweise eine bestimmte Art und Weise, wie der Entwickler den generierten Code missbraucht haben könnte, um die Struktur der ausgeführten SQL-Abfragen zu ändern und/oder völlig neue SQL-Abfragen zu injizieren.

Ein Angreifer ändert die Parameter der SOAP-Nachricht, die vom Dienstkonsumenten an den Dienstanbieter gesendet wird, um einen SQL-Injection-Angriff zu initiieren. Auf der Seite des Dienstanbieters wird die SOAP-Nachricht geparst und die Parameter werden nicht ordnungsgemäß validiert, bevor sie für den Zugriff auf eine Datenbank auf eine Art und Weise verwendet werden, die keine Parameterbindung verwendet, wodurch der Angreifer die Struktur der ausgeführten SQL-Abfrage kontrollieren kann. Dieses Muster beschreibt einen SQL-Injection-Angriff, wobei der Übermittlungsmechanismus eine SOAP-Nachricht ist. Detect Incorrect SOAP Parameter Handling] Der Angreifer manipuliert die Parameter der SOAP-Nachricht und sucht nach Anzeichen dafür, dass die Manipulation eine Änderung im Verhalten der Zielanwendung verursacht hat. [Probe for SQL Injection vulnerability] Der Angreifer injiziert SQL-Syntax in anfällige SOAP-Parameter, die in der Explore-Phase identifiziert wurden, und sucht nach der ungefilterten Ausführung der SQL-Syntax in einer Abfrage. SQL-Injektion über SOAP-Parameter] Der Angreifer injiziert SQL über SOAP-Parameter, die in der Explore-Phase als anfällig identifiziert wurden, um einen SQL-Injektionsangriff erster oder zweiter Ordnung zu starten.

Der Angreifer nutzt eine Wiederholung des Kodierungsprozesses für einen Satz von Zeichen (d. h. eine Zeichenkodierung einer Zeichenkodierung eines Zeichens), um die Nutzdaten einer bestimmten Anfrage zu verschleiern. Dies kann es dem Angreifer ermöglichen, Filter zu umgehen, die versuchen, illegale Zeichen oder Zeichenketten zu erkennen, z. B. solche, die in Traversal- oder Injection-Angriffen verwendet werden könnten. Filter können zwar illegale kodierte Zeichenfolgen abfangen, aber möglicherweise keine doppelt kodierten Zeichenfolgen. Zum Beispiel könnte ein Punkt (.), der oft in Path-Traversal-Angriffen verwendet und daher oft von Filtern blockiert wird, als %2E URL-kodiert sein. Viele Filter erkennen jedoch diese Kodierung und würden die Anfrage trotzdem blockieren. Bei einer doppelten Kodierung würde das % in der obigen URL-Kodierung noch einmal als %25 kodiert werden, was zu %252E führt, das von einigen Filtern möglicherweise nicht erkannt wird, aber von Interpretern auf dem Ziel immer noch als Punkt (.) interpretiert werden könnte. [Untersuchen Sie die Anwendung auf benutzergesteuerte Eingaben] Mit einem Browser, einem automatisierten Tool oder durch Inspektion der Anwendung erfasst ein Angreifer alle Einstiegspunkte in die Anwendung. Eingangspunkte untersuchen, um Schwachstellen zu finden] Versuchen Sie, Teile der Eingaben doppelt zu kodieren, um zu versuchen, die Filter zu umgehen. Durch die doppelte Kodierung bestimmter Zeichen in der URL (z. B. Punkte und Schrägstriche) kann ein Angreifer beispielsweise versuchen, Zugriff auf eingeschränkte Ressourcen auf dem Webserver zu erhalten oder das Browsen zu geschützten Seiten zu erzwingen (und so den Autorisierungsdienst zu unterlaufen). Ein Angreifer kann mit diesem Angriffsmuster auch andere Angriffe im Injektionsstil versuchen: Befehlsinjektion, SQL-Injektion usw.

Der Angreifer verändert direkt oder indirekt die Umgebungsvariablen, die von der Zielsoftware verwendet werden oder diese steuern. Das Ziel des Angreifers ist es, die Zielsoftware dazu zu bringen, von ihrem erwarteten Betrieb in einer Weise abzuweichen, die dem Angreifer nützt. [Sondieren der Zielanwendung] Der Angreifer sondiert zunächst die Zielanwendung, um wichtige Informationen über das Ziel zu ermitteln. Zu diesen Informationen gehören z. B. die Art der verwendeten Software, die Softwareversionen, die Benutzereingaben, die die Anwendung verarbeitet, usw. Vor allem aber versucht der Angreifer herauszufinden, welche Umgebungsvariablen von der zugrunde liegenden Software oder sogar von der Anwendung selbst verwendet werden könnten. [Anhand der durch die Untersuchung der Anwendung gefundenen Informationen versucht der Angreifer, alle benutzergesteuerten Umgebungsvariablen zu manipulieren, von denen er herausgefunden hat, dass sie von der Anwendung verwendet werden oder von denen er annimmt, dass sie von der Anwendung verwendet werden, und beobachtet die Auswirkungen dieser Änderungen. Wenn der Angreifer signifikante Änderungen an der Anwendung feststellt, weiß er, dass eine bestimmte Umgebungsvariable für das Verhalten der Anwendung wichtig ist und einen möglichen Angriffsvektor darstellt. [Manipulation von benutzergesteuerten Umgebungsvariablen] Der Angreifer manipuliert die gefundene(n) Umgebungsvariable(n), um den normalen Ablauf von Prozessen zu missbrauchen oder Zugriff auf privilegierte Ressourcen zu erhalten.

Ein Angreifer fügt Formatierungszeichen in ein String-Eingabefeld der Zielanwendung ein. Die meisten Anwendungen gehen davon aus, dass der Benutzer statischen Text eingibt und reagieren möglicherweise unvorhersehbar auf das Vorhandensein von Formatierungszeichen. In bestimmten Funktionen der Programmiersprachen C, wie z. B. printf, gibt das Formatierungszeichen %s den Inhalt einer Speicherstelle in der Erwartung aus, dass diese Stelle eine Zeichenfolge identifiziert, und das Formatierungszeichen %n gibt die Anzahl der in den Speicher geschriebenen DWORD aus. Ein Angreifer kann dies nutzen, um Speicherstellen oder Dateien zu lesen oder zu beschreiben oder einfach den Wert des resultierenden Textes auf unerwartete Weise zu manipulieren. Das Lesen oder Schreiben von Speicher kann zu Programmabstürzen führen und das Schreiben von Speicher kann zur Ausführung von beliebigem Code führen, wenn der Angreifer in den Programmstapel schreiben kann. [Anwendung untersuchen] Der Angreifer nimmt eine Bestandsaufnahme der Einstiegspunkte der Anwendung vor. Bestimmen Sie die benutzerkontrollierbaren Eingaben, die für eine Format-String-Injektion anfällig sind. Versuchen Sie, für jede benutzerkontrollierbare Eingabe, von der der Angreifer annimmt, dass sie für Format-String-Injection anfällig ist, Formatierungszeichen wie %n, %s usw. zu injizieren. Ziel ist es, die String-Erstellung mit diesen Formatierungszeichen zu manipulieren. [Versuchen Sie, die Format-String-Injection-Schwachstelle auszunutzen] Nachdem Sie festgestellt haben, dass eine bestimmte Eingabe für die Format-String-Injection anfällig ist, stellen Sie Hypothesen darüber auf, wie die zugrunde liegende Verwendung aussieht und welche Einschränkungen damit verbunden sind.

Ein Angreifer manipuliert oder bastelt eine LDAP-Abfrage mit dem Ziel, die Sicherheit des Ziels zu untergraben. Einige Anwendungen verwenden Benutzereingaben zur Erstellung von LDAP-Abfragen, die von einem LDAP-Server verarbeitet werden. So kann ein Benutzer beispielsweise bei der Authentifizierung seinen Benutzernamen angeben, der dann während des Authentifizierungsprozesses in eine LDAP-Abfrage eingefügt wird. Ein Angreifer könnte diese Eingabe nutzen, um zusätzliche Befehle in eine LDAP-Abfrage einzuschleusen, die sensible Informationen offenlegen könnten. So könnte beispielsweise die Eingabe eines * in der oben genannten Abfrage Informationen über alle Benutzer des Systems zurückgeben. Dieser Angriff ist einem SQL-Injection-Angriff sehr ähnlich, da er eine Abfrage manipuliert, um zusätzliche Informationen zu sammeln oder einen bestimmten Rückgabewert zu erzwingen. [Vermessung der Anwendung] Der Angreifer nimmt eine Bestandsaufnahme der Einstiegspunkte der Anwendung vor. [Bestimmen der vom Benutzer kontrollierbaren Eingaben, die für LDAP-Injection anfällig sind] Für jede vom Benutzer kontrollierbare Eingabe, von der der Angreifer vermutet, dass sie für LDAP-Injection anfällig ist, versucht er, Zeichen zu injizieren, die in LDAP eine besondere Bedeutung haben (z. B. ein einzelnes Anführungszeichen usw.). Ziel ist es, eine LDAP-Abfrage mit einer ungültigen Syntax zu erstellen [Versuchen Sie, die LDAP-Injection-Schwachstelle auszunutzen] Nachdem Sie festgestellt haben, dass eine bestimmte Eingabe für LDAP-Injection anfällig ist, stellen Sie Hypothesen darüber auf, wie die zugrunde liegende Abfrage aussieht. Versuchen Sie, möglicherweise mit Hilfe eines Tools, der Abfrage iterativ Logik hinzuzufügen, um Informationen aus dem LDAP zu extrahieren oder Informationen im LDAP zu ändern oder zu löschen.

Bei dieser Art von Angriff wird eine Pufferüberlaufschwachstelle in der Ziel-Clientsoftware ausgenutzt, indem bösartige Inhalte von einem speziell entwickelten feindlichen Dienst eingeschleust werden. Dieser feindliche Dienst wird erstellt, um den richtigen Inhalt an die Client-Software zu liefern. Wenn es sich bei der clientseitigen Anwendung beispielsweise um einen Browser handelt, hostet der Dienst eine Webseite, die der Browser lädt. [Der Angreifer identifiziert eine clientseitige Zielanwendung, um den Pufferüberlauf durchzuführen. Am häufigsten sind dies Browser. Wenn es eine bekannte Browser-Schwachstelle gibt, könnte ein Angreifer diese angreifen. [Injektionsvektor finden] Der Angreifer identifiziert einen Injektionsvektor, um den übermäßigen Inhalt in den Puffer der Zielanwendung zu übertragen. [Erstellen eines feindlichen Dienstes] Der Angreifer erstellt einen feindlichen Dienst, der Inhalte an die clientseitige Anwendung liefert. Wenn die Absicht darin besteht, die Software einfach zum Absturz zu bringen, muss der Inhalt nur aus einer übermäßigen Menge an Zufallsdaten bestehen. Wenn die Absicht darin besteht, den Überlauf zur Ausführung von beliebigem Code zu nutzen, gestaltet der Angreifer die Nutzlast so, dass die überschriebene Rücksprungadresse durch eine Adresse seiner Wahl ersetzt wird. [Überlauf des Puffers] Mit Hilfe des Injektionsvektors liefert der Angreifer den Inhalt an die clientseitige Anwendung, die den feindlichen Dienst nutzt, und lässt den Puffer überlaufen.

Ein Angreifer nutzt eine Schwachstelle bei der Eingabevalidierung aus, indem er das Format, die Struktur und die Zusammensetzung der Daten für eine Eingabeverarbeitungsschnittstelle kontrolliert. Durch die Eingabe von Daten in einer nicht standardisierten oder unerwarteten Form kann ein Angreifer die Sicherheit des Ziels beeinträchtigen.

Ein Angreifer bringt ein Opfer dazu, bösartige Flash-Inhalte auszuführen, die Befehle ausführen oder Flash-Aufrufe tätigen, die vom Angreifer festgelegt wurden. Ein Beispiel für diesen Angriff ist das Cross-Site-Flashing, bei dem ein vom Angreifer kontrollierter Parameter eines Referenzaufrufs von einem vom Angreifer angegebenen Inhalt geladen wird. [Finde Einschleusungspunkte] Der Angreifer nimmt zunächst eine Bestandsaufnahme der Einschleusungspunkte der Anwendung vor. [Ermitteln der Anfälligkeit der Anwendung für Flash-Injection] Ermitteln der Anfälligkeit der Anwendung für Flash-Injection. Für jede in der Erkundungsphase ermittelte URL versucht der Angreifer, verschiedene Techniken wie direktes Laden als Funktion, kontrollierte bösartige Seite/Host, Flash-HTML-Injektion und DOM-Injektion einzusetzen, um festzustellen, ob die Anwendung für Flash-Injection anfällig ist. [Einschleusen bösartiger Inhalte in das Ziel] Einschleusen bösartiger Inhalte in das Ziel unter Verwendung der in der Experimentierphase identifizierten anfälligen Einschleusungsvektoren

Ein Angreifer erstellt eine Datei mit Skript-Inhalt, wobei der angegebene MIME-Typ der Datei so beschaffen ist, dass Skripte nicht erwartet werden. Der Angreifer bringt das Opfer dazu, auf eine URL zuzugreifen, die mit der Skriptdatei antwortet. Einige Browser erkennen, dass der angegebene MIME-Typ der Datei nicht mit dem tatsächlichen Typ ihres Inhalts übereinstimmt, und schalten automatisch auf die Verwendung eines Interpreters für den tatsächlichen Inhaltstyp um. Wenn der Browser vorher keine Skriptfilter aufruft, kann das Skript des Angreifers auf dem Ziel unkontrolliert ausgeführt werden und möglicherweise die Cookies des Opfers preisgeben oder ein beliebiges Skript in dessen Browser ausführen. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Bereiche auf, die es einem Benutzer ermöglichen, Inhalte über eine HTTP-POST-Anforderung hochzuladen. Dies ist typischerweise in Blogs oder Foren der Fall. [Der Angreifer verwendet die in der "Explore"-Phase erfassten Einstiegspunkte als Zielliste und lädt Dateien mit Skriptinhalten hoch, deren MIME-Typ jedoch als Dateityp angegeben ist, der keine Skriptinhalte ausführen kann. Wenn die Anwendung nur den MIME-Typ der Datei überprüft, kann sie die Datei durchlassen, so dass das Skript von jedem Benutzer, der auf die Datei zugreift, ausgeführt wird. [Sobald der Angreifer herausgefunden hat, welche Datei-Upload-Speicherorte für MIME-Typ-Fehlanpassungen anfällig sind, lädt er ein bösartiges Skript hoch, das als nicht skriptfähige Datei getarnt ist. Der Angreifer kann viele Ziele verfolgen, vom Diebstahl von Sitzungs-IDs, Cookies, Anmeldedaten und Seiteninhalten eines Opfers. [Damit der Angriff erfolgreich ist, muss das Opfer den gespeicherten bösartigen Inhalt auf der Webseite sehen.

Ein Angriff dieser Art nutzt Schwachstellen in der Authentifizierung und Datenintegrität des Client/Server-Kommunikationskanals aus. Er nutzt das implizite Vertrauen aus, das ein Server in den Client setzt, oder, noch wichtiger, in das, was der Server für den Client hält. Ein Angreifer führt diese Art von Angriff aus, indem er direkt mit dem Server kommuniziert, wobei der Server glaubt, dass er nur mit einem gültigen Client kommuniziert. Es gibt zahlreiche Variationen dieser Art von Angriff.

Ein Angreifer vergiftet Dateien mit einer bösartigen Nutzlast (die auf die von der Zielsoftware zugänglichen Dateisysteme abzielt), die über Standardkanäle wie E-Mail und Standard-Webinhalte wie PDF- und Multimediadateien weitergeleitet werden kann. Der Angreifer nutzt bekannte Schwachstellen oder Verarbeitungsroutinen in den Zielprozessen aus, um das Vertrauen des Hosts in die Ausführung von Remote-Inhalten, einschließlich Binärdateien, auszunutzen.

Anwendungen müssen häufig Daten mithilfe eines Parsers in ein und aus einem Datenformat (z. B. XML und YAML) umwandeln. Ein Angreifer könnte Daten einschleusen, die sich bei der Verarbeitung des Parsers nachteilig auswirken könnten. Viele Datenformatsprachen erlauben die Definition von makroähnlichen Strukturen, die zur Vereinfachung der Erstellung komplexer Strukturen verwendet werden können. Durch die Verschachtelung dieser Strukturen und das wiederholte Ersetzen von Daten kann ein Angreifer den Parser dazu bringen, während der Verarbeitung mehr Ressourcen zu verbrauchen, was zu einem übermäßigen Speicherverbrauch und einer übermäßigen CPU-Auslastung führt. Ein Angreifer bestimmt den Eingabedatenstrom, der von einem Datenparser verarbeitet wird, der die Verwendung von Substitution auf der Seite des Opfers unterstützt. Ein Angreifer manipuliert Eingabedaten, die sich negativ auf den Betrieb des Parsers auswirken können, wenn die Daten auf dem System des Opfers geparst werden.

Ein Angreifer fügt während der Datenverarbeitung übergroße serialisierte Daten-Nutzdaten in einen Parser ein, um negative Auswirkungen auf den Parser zu erzeugen, wie z. B. die Erschöpfung von Systemressourcen und die Ausführung von beliebigem Code. Ein Angreifer ermittelt den Eingabedatenstrom, der von einem Parser für serialisierte Daten auf der Seite des Opfers verarbeitet wird. Ein Angreifer fabriziert Eingabedaten, die sich negativ auf den Betrieb des Datenparsers auswirken können, wenn die Daten auf dem System des Opfers geparst werden.

Bei diesem Angriff geht es darum, einen aktiven Filter zum Versagen zu bringen, indem eine übergroße Transaktion verursacht wird. Ein Angreifer kann versuchen, das Programm mit überlangen Eingabestrings zu füttern, um den Filter zu überwältigen (indem er einen Pufferüberlauf verursacht) und zu hoffen, dass der Filter nicht sicher versagt (d. h. die Benutzereingabe wird ungefiltert in das System gelassen). [Survey] Der Angreifer untersucht die Zielanwendung, möglicherweise als gültiger und authentifizierter Benutzer [Attempt Injections] Er versucht, dem System übermäßig lange Daten zuzuführen. Dies kann manuell geschehen oder mit einem dynamischen Tool (Blackbox) automatisiert werden. Ein Angreifer kann zu diesem Zweck auch ein eigenes Skript verwenden. [Antworten überwachen] Achten Sie auf alle Anzeichen eines Fehlers. Beobachten Sie sorgfältig, was passiert ist, als der Filterfehler auftrat. Sind die Daten angekommen? [Ein Angreifer schreibt ein Skript, um das Versagen des Filters konsequent herbeizuführen.

Ein Angreifer verwendet manipulierte benutzerkontrollierbare XML-Eingaben, um die XML-Datenbank zu untersuchen, anzugreifen und Daten in sie einzuschleusen, wobei er ähnliche Techniken wie bei der SQL-Injektion verwendet. Die benutzerkontrollierbare Eingabe kann die unbefugte Anzeige von Daten, die Umgehung der Authentifizierung oder der Front-End-Anwendung für den direkten XML-Datenbankzugriff und möglicherweise die Änderung von Datenbankinformationen ermöglichen. [Überprüfen Sie das Ziel] Mit Hilfe eines Browsers oder eines automatisierten Tools zeichnet ein Angreifer alle Instanzen von benutzerkontrollierbaren Eingaben auf, die zur Erstellung von XML-Abfragen verwendet werden [Bestimmen Sie die Struktur der Abfragen] Testen Sie die gefundenen Eingaben mit manuellen oder automatisierten Mitteln auf XML-Schwachstellen. [Einschleusen von Inhalten in XML-Abfragen] Erstellen von bösartigen Inhalten mit XML-Ausdrücken, die von der Anwendung nicht validiert und als Teil der XML-Abfragen ausgeführt werden.

Ein Angreifer, der berechtigt ist, Abfragen an ein Ziel zu senden, sendet Varianten der erwarteten Abfragen in der Hoffnung, dass diese modifizierten Abfragen (direkt oder indirekt über Fehlerprotokolle) Informationen liefern, die über die erwarteten Abfragen hinausgehen. [Kommunikation und Eingaben beobachten] Der Fuzzing-Angreifer beobachtet das Zielsystem und sucht nach Eingaben und Kommunikation zwischen Modulen, Subsystemen oder Systemen. [Generieren von Fuzzing-Eingaben] Mit einem Fuzzing-Tool, einer Zieleingabe oder einem Protokoll und Beschränkungen hinsichtlich Zeit, Komplexität und Eingabevielfalt wird eine Liste von Eingaben erstellt, die ausprobiert werden sollen. Obwohl Fuzzing zufällig ist, ist es nicht erschöpfend. Parameter wie die Länge, die Zusammensetzung und die Anzahl der auszuprobierenden Variationen sind wichtig, um die kostengünstigste Wirkung des Fuzzers zu erzielen. [Beobachten Sie die Ergebnisse] Beobachten Sie die Ausgaben zu den Eingaben, die von den Fuzzern in das System eingespeist werden, und sehen Sie nach, ob es Protokoll- oder Fehlermeldungen gibt, die entweder Benutzer- bzw. sensible Daten liefern oder Informationen über eine erwartete Vorlage geben, die zur Erzeugung dieser Daten verwendet werden könnte. [Wenn die Protokolle keine benutzerbezogenen/sensiblen Daten enthielten, wird ein Angreifer versuchen, die Fuzzing-Eingaben zu einer erwarteten Vorlage zu formen.

Ein Angreifer nutzt die Möglichkeit, potenziell schädliche Eingaben oder Inhalte, die von Anwendungen verwendet werden, so zu kodieren, dass die Anwendungen bei der Validierung dieses Kodierungsstandards unwirksam sind. [Untersuchung der Anwendung auf benutzerkontrollierbare Eingaben] Mit Hilfe eines Browsers, eines automatisierten Tools oder durch Inspektion der Anwendung erfasst ein Angreifer alle Einstiegspunkte in die Anwendung. [Der Angreifer verwendet die in der Erkundungsphase gesammelten Eingangspunkte als Zielliste und injiziert verschiedene Nutzdaten unter Verwendung einer Vielzahl unterschiedlicher Kodierungsarten, um festzustellen, ob ein Eingangspunkt tatsächlich eine Schwachstelle mit unzureichender Validierungslogik darstellt, und um das Ausmaß zu charakterisieren, in dem die Schwachstelle ausgenutzt werden kann.

Bei diesem Angriffsmuster nutzt der Angreifer Fuzzing, um zu versuchen, Schwachstellen im System zu identifizieren. Fuzzing ist eine Methode zum Testen von Software-Sicherheit und -Funktionalität, bei der das System mit zufällig erzeugten Eingaben gefüttert wird und nach Anzeichen dafür gesucht wird, dass als Reaktion auf diese Eingaben ein Fehler aufgetreten ist. Fuzzing behandelt das System als Black Box und ist völlig frei von jeglichen Vorurteilen oder Annahmen über das System. Fuzzing kann einem Angreifer helfen, bestimmte Annahmen über Benutzereingaben im System zu entdecken. Fuzzing gibt einem Angreifer eine schnelle Möglichkeit, einige dieser Annahmen aufzudecken, obwohl er nicht unbedingt etwas über die Interna des Systems weiß. Diese Annahmen können dann gegen das System verwendet werden, indem Benutzereingaben speziell so gestaltet werden, dass ein Angreifer seine Ziele erreichen kann. [Kommunikation und Eingaben beobachten] Der Fuzzing-Angreifer beobachtet das Zielsystem und sucht nach Eingaben und Kommunikation zwischen Modulen, Subsystemen oder Systemen. Generieren von Fuzzing-Eingaben] Mit einem Fuzzing-Tool, einer Zieleingabe oder einem Protokoll und Beschränkungen hinsichtlich Zeit, Komplexität und Eingabevielfalt wird eine Liste von Eingaben generiert, die ausprobiert werden sollen. Obwohl Fuzzing zufällig ist, ist es nicht erschöpfend. Parameter wie die Länge, die Zusammensetzung und die Anzahl der auszuprobierenden Variationen sind wichtig, um die kosteneffektivste Wirkung des Fuzzers zu erzielen. Beobachten Sie die Ergebnisse] Beobachten Sie die Ausgaben zu den Eingaben, die von Fuzzern in das System eingespeist werden, und sehen Sie, ob etwas Interessantes passiert. Wenn ein Fehler auftritt, bestimmen Sie, warum das passiert ist. Finden Sie die zugrundeliegende Annahme heraus, die durch die Eingabe entkräftet wurde. Speziell angefertigte Eingaben in das System einspeisen, die die durch Fuzzing identifizierte Schwäche ausnutzen und es ermöglichen, die Ziele des Angreifers zu erreichen. Fuzzer zeigen oft Wege auf, um durch die Eingabevalidierungsfilter zu schlüpfen und unerwünschte Daten in das System einzuschleusen.

Einige APIs entfernen bestimmte führende Zeichen aus einer Zeichenkette von Parametern. Ein Angreifer kann absichtlich führende "Ghost"-Zeichen (zusätzliche Zeichen, die die Gültigkeit der Anfrage auf der API-Ebene nicht beeinträchtigen) einfügen, die es der Eingabe ermöglichen, die Filter zu passieren und somit die Eingabe des Angreifers zu verarbeiten. Dies ist der Fall, wenn die anvisierte API Eingabedaten in verschiedenen syntaktischen Formen akzeptiert und sie auf die entsprechende semantische Weise interpretiert, während der Filter nicht das gesamte Spektrum der für die anvisierte API akzeptablen syntaktischen Formen berücksichtigt. [Untersuchung der Anwendung auf vom Benutzer kontrollierbare Eingaben] Mit Hilfe eines Browsers, eines automatisierten Tools oder durch Inspektion der Anwendung erfasst ein Angreifer alle Eingangspunkte zur Anwendung. [Der Angreifer verwendet die in der "Erkundungsphase" gesammelten Eingangspunkte als Zielliste und injiziert verschiedene führende "Ghost"-Zeichenfolgen, um zu ermitteln, wie die Anwendung sie filtert. [Umgehen der Eingabefilterung] Mit dem, was der Angreifer über die Art und Weise, wie die Anwendung Eingabedaten filtert, erfahren hat, stellt er spezifische Eingabedaten her, die den Filter umgehen. Dies kann zu Angriffen auf Verzeichnisse, die Ausführung beliebiger Shell-Befehle, die Beschädigung von Dateien usw. führen.

Dieser Angriff stützt sich auf die Verwendung von HTTP-Cookies, um Anmeldeinformationen, Statusinformationen und andere kritische Daten auf Client-Systemen zu speichern. Es gibt mehrere verschiedene Formen dieses Angriffs. Bei der ersten Form dieses Angriffs wird auf HTTP-Cookies zugegriffen, um die darin enthaltenen potenziell sensiblen Daten abzugreifen. Bei der zweiten Form werden diese Daten abgefangen, während sie vom Client zum Server übertragen werden. Diese abgefangenen Informationen werden dann vom Angreifer verwendet, um sich als der entfernte Benutzer/Sitzung auszugeben. Die dritte Form besteht darin, dass der Inhalt des Cookies vom Angreifer verändert wird, bevor er an den Server zurückgesendet wird. Hier versucht der Angreifer, den Zielserver davon zu überzeugen, mit diesen gefälschten Informationen zu arbeiten. Der Angreifer muss sich zunächst eine Kopie des Cookies beschaffen. Bei dem Angreifer kann es sich um einen legitimen Endbenutzer handeln, der seine Privilegien ausweiten möchte, oder um jemanden, der in einem Netzwerk schnüffelt, um eine Kopie von HTTP-Cookies zu erhalten. Der Angreifer könnte in der Lage sein, sensible Informationen aus dem Cookie zu erhalten. Die Entwickler der Webanwendung sind möglicherweise davon ausgegangen, dass Cookies für Endbenutzer nicht zugänglich sind, und haben daher möglicherweise sensible Informationen in ihnen abgelegt. Cookie modifizieren, um Sicherheitskontrollen zu umgehen] Der Angreifer kann möglicherweise Cookies modifizieren oder ersetzen, um Sicherheitskontrollen in der Anwendung zu umgehen.

Ein Angreifer nutzt eine Schwachstelle in der MIME-Konvertierungsroutine aus, um einen Pufferüberlauf zu verursachen und die Kontrolle über den Mailserver zu erlangen. Das MIME-System ist so konzipiert, dass verschiedene Informationsformate interpretiert und per E-Mail verschickt werden können. Angriffspunkte bestehen, wenn Daten in ein MIME-kompatibles Format und zurück konvertiert werden. [Identifizierung des Ziel-Mailservers] Der Angreifer identifiziert einen Ziel-Mailserver, den er angreifen möchte. [Bestimmen der Durchführbarkeit des Angriffs] Bestimmen, ob der Mailserver ungepatcht und potenziell anfällig für einen der bekannten MIME-Konvertierungspufferüberläufe ist (z. B. Sendmail 8.8.3 und 8.8.4). [Injektionsvektor finden] Identifizieren Sie Stellen im System, an denen anfällige MIME-Konvertierungsroutinen verwendet werden können. [Craft overflow content] Der Angreifer bastelt E-Mail-Nachrichten mit speziellen Kopfzeilen, die einen Pufferüberlauf für die anfällige MIME-Konvertierungsroutine verursachen. Ziel dieses Angriffs ist es, den Überlauf zur Ausführung von beliebigem Code zu nutzen und Zugriff auf den Mailserver zu erlangen. Der Angreifer bastelt also eine E-Mail, die nicht nur den anvisierten Puffer überläuft, sondern dies auch so tut, dass die überschriebene Absenderadresse durch eine vom Angreifer gewählte ersetzt wird. [Pufferüberlauf] Senden Sie E-Mail-Nachrichten an das Zielsystem mit speziell gestalteten Kopfzeilen, die den Pufferüberlauf auslösen und den Shell-Code ausführen.

Ein Angreifer versorgt die Zielsoftware mit Eingabedaten, die Sequenzen von Sonderzeichen enthalten, mit denen die Logik der Eingabeüberprüfung umgangen werden soll. Diese Schwachstelle beruht darauf, dass die Zielsoftware die Eingabedaten mehrfach durchläuft und bei jedem Durchlauf eine "Schicht" von Sonderzeichen verarbeitet. Auf diese Weise kann der Angreifer Eingaben verschleiern, die andernfalls als ungültig zurückgewiesen würden, indem er sie mit Schichten von Sonder-/Escape-Zeichen überdeckt, die in den nachfolgenden Verarbeitungsschritten entfernt werden. Das Ziel besteht darin, zunächst Fälle zu entdecken, in denen die Eingabevalidierungsschicht vor einer oder mehreren Parsing-Schichten ausgeführt wird. Das heißt, die Benutzereingabe kann in einer Anwendung die folgende Logik durchlaufen: <Parser1> --> <Eingabevalidierer> --> <Parser2>. In solchen Fällen muss der Angreifer eine Eingabe bereitstellen, die den Eingabevalidierer durchläuft, aber nach dem Durchlaufen von Parser2 in etwas umgewandelt wird, das der Eingabevalidierer eigentlich verhindern sollte. [Der Angreifer muss zunächst alle Eingaben der Anwendung/des Systems ermitteln, bei denen eine Eingabeüberprüfung durchgeführt wird und bei denen er diese umgehen möchte. [Bestimmen, welche Zeichenkodierungen von der Anwendung/dem System akzeptiert werden] Der Angreifer muss dann der Anwendung/dem System verschiedene Zeichenkodierungen zur Verfügung stellen und feststellen, welche davon akzeptiert werden. Der Angreifer muss die Reaktion der Anwendung/des Systems auf die kodierten Daten beobachten, um festzustellen, ob die Daten richtig interpretiert wurden. [Kombinieren mehrerer von der Anwendung akzeptierter Verschlüsselungen] Der Angreifer kombiniert nun die von der Anwendung akzeptierten Verschlüsselungen. Der Angreifer kann verschiedene Verschlüsselungen kombinieren oder dieselbe Verschlüsselung mehrfach anwenden. [Der Angreifer nutzt seine Fähigkeit, die Eingabevalidierung zu umgehen, um unbefugten Zugriff auf das System zu erhalten. Es gibt viele mögliche Angriffe, von denen hier einige Beispiele genannt werden.

Diese Art von Angriff nutzt die Verwendung von symbolischen Links, um Pufferüberläufe zu verursachen. Ein Angreifer kann versuchen, eine symbolische Link-Datei so zu erstellen oder zu manipulieren, dass ihr Inhalt zu Daten führt, die außerhalb der Grenzen liegen. Wenn die Zielsoftware die symbolische Link-Datei verarbeitet, kann sie bei unzureichender Prüfung der Grenzen möglicherweise interne Puffer überlaufen lassen. [Identifizieren der Zielanwendung] Der Angreifer identifiziert eine Zielanwendung oder ein Programm, das bestimmte Dateien in den Speicher laden könnte. [Injektionsvektor finden] Der Angreifer identifiziert einen Injektionsvektor, um den übermäßigen Inhalt in den Puffer der Zielanwendung zu übertragen. [Craft overflow file content] Der Angreifer stellt den zu injizierenden Inhalt her. Wenn die Absicht darin besteht, die Software einfach zum Absturz zu bringen, muss der Inhalt nur aus einer übermäßigen Menge an Zufallsdaten bestehen. Wenn die Absicht darin besteht, den Überlauf zur Ausführung von beliebigem Code zu nutzen, stellt der Angreifer die Nutzlast so her, dass die überschriebene Rücksprungadresse durch eine Adresse seiner Wahl ersetzt wird. [Pufferüberlauf] Mithilfe des speziell gestalteten Dateiinhalts erstellt der Angreifer einen symbolischen Link von der identifizierten Ressource zur bösartigen Datei, wodurch ein gezielter Pufferüberlauf-Angriff ausgelöst wird.

Diese Art von Angriff nutzt die Verwendung von Tags oder Variablen aus formatierten Konfigurationsdaten aus, um einen Pufferüberlauf zu verursachen. Der Angreifer erstellt eine bösartige HTML-Seite oder Konfigurationsdatei, die übergroße Zeichenfolgen enthält und so einen Überlauf verursacht. [Zielanwendung identifizieren] Der Angreifer identifiziert eine Zielanwendung oder ein Zielprogramm, um den Pufferüberlauf auszuführen. Der Angreifer sucht nach Anwendungen oder Programmen, die formatierte Dateien, wie z. B. Konfigurationsdateien, als Eingabe akzeptieren. [Finde Injektionsvektor] Der Angreifer identifiziert einen Injektionsvektor, um den übermäßigen Inhalt in den Puffer der Zielanwendung zu übertragen. [Craft overflow content] Der Angreifer stellt den zu injizierenden Inhalt her. Wenn die Absicht darin besteht, die Software einfach zum Absturz zu bringen, muss der Inhalt nur aus einer übermäßigen Menge an Zufallsdaten bestehen. Wenn die Absicht darin besteht, den Überlauf zur Ausführung von beliebigem Code zu nutzen, stellt der Angreifer die Nutzlast so her, dass die überschriebene Rücksprungadresse durch eine Adresse seiner Wahl ersetzt wird. [Pufferüberlauf] Der Angreifer lädt die manipulierte Datei in die Anwendung hoch und verursacht einen Pufferüberlauf.

Bei diesem Angriff erhält die Zielsoftware Eingaben, von denen der Angreifer weiß, dass sie während der Verarbeitung geändert und in ihrer Größe erweitert werden. Dieser Angriff beruht darauf, dass die Zielsoftware nicht antizipiert, dass die erweiterten Daten eine interne Grenze überschreiten könnten, wodurch ein Pufferüberlauf entsteht. [Identifizieren der Zielanwendung] Der Angreifer identifiziert eine Zielanwendung oder ein Zielprogramm, um den Pufferüberlauf durchzuführen. Angreifer suchen oft nach Anwendungen, die Benutzereingaben akzeptieren und eine manuelle Speicherverwaltung durchführen. [Injektionsvektor finden] Der Angreifer identifiziert einen Injektionsvektor, um den übermäßigen Inhalt in den Puffer der Zielanwendung zu übertragen. [Craft overflow content] Der Angreifer stellt die an das Programm zu übergebende Eingabe her. Wenn die Absicht darin besteht, die Software einfach zum Absturz zu bringen, muss die Eingabe nur zu einer übermäßigen Menge an Zufallsdaten erweitert werden. Wenn die Absicht darin besteht, den Überlauf für die Ausführung von beliebigem Code zu nutzen, wird der Angreifer die Eingabe so gestalten, dass sie nicht nur den Zielpuffer überläuft, sondern auch so, dass die überschriebene Rücksprungadresse durch eine Adresse nach Wahl des Angreifers ersetzt wird, die auf vom Angreifer eingeschleusten Code verweist. [Überlauf des Puffers] Mit Hilfe des Injektionsvektors gibt der Angreifer die manipulierte Eingabe an das Programm weiter, wodurch der Puffer überläuft.

Ein Angreifer generiert eine Nachricht oder einen Datenblock, der den Empfänger glauben lässt, dass die Nachricht oder der Datenblock von einer autorisierten oder seriösen Quelle generiert und kryptografisch signiert wurde, wodurch ein Opfer oder ein Opfer-Betriebssystem dazu verleitet wird, bösartige Aktionen durchzuführen.

Ein Angreifer bettet ein oder mehrere Null-Bytes in die Eingabe der Zielsoftware ein. Dieser Angriff beruht auf der Verwendung eines nullwertigen Bytes als String-Terminator in vielen Umgebungen. Das Ziel ist, dass bestimmte Komponenten der Zielsoftware die Verarbeitung der Eingabe stoppen, wenn sie auf das/die Null-Byte(s) stoßen. [Mit Hilfe eines Browsers, eines automatisierten Tools oder durch Inspektion der Anwendung zeichnet ein Angreifer alle Einstiegspunkte in die Anwendung auf. [Der Angreifer verwendet die in der Erkundungsphase gesammelten Einstiegspunkte als Zielliste und injiziert Postfix-Null-Byte(s), um zu beobachten, wie die Anwendung diese als Eingaben verarbeitet. Der Angreifer sucht nach Bereichen, in denen Benutzereingaben in der Mitte einer Zeichenkette platziert werden und das Null-Byte die Anwendung veranlasst, die Verarbeitung der Zeichenkette am Ende der Benutzereingabe zu beenden. [Daten nach dem/den Null-Byte(s) entfernen] Nachdem der Angreifer die verwundbaren Einstiegspunkte ermittelt hat, platziert er ein oder mehrere Null-Byte(s) so, dass er die Daten nach dem/den Null-Byte(s) auf eine für ihn vorteilhafte Weise entfernt.

Wenn eine Zeichenkette einen Filter durchläuft, ist ein terminaler NULL-Wert möglicherweise nicht gültig. Die Verwendung einer alternativen NULL-Darstellung ermöglicht es einem Angreifer, die NULL in der Mitte der Zeichenkette einzubetten und gleichzeitig die richtigen Daten zu postfixieren, so dass der Filter umgangen wird. Ein Beispiel ist ein Filter, der nach einem nachgestellten Schrägstrich sucht. Wenn eine Zeichenfolgeneinfügung möglich ist, der Schrägstrich aber vorhanden sein muss, kann eine alternative Kodierung von NULL in der Mitte der Zeichenfolge verwendet werden. [Untersuchung der Anwendung auf benutzerkontrollierbare Eingaben] Mithilfe eines Browsers, eines automatisierten Tools oder durch Inspektion der Anwendung erfasst ein Angreifer alle Einstiegspunkte in die Anwendung. [Der Angreifer verwendet die in der "Erkundungsphase" gesammelten Einstiegspunkte als Zielliste und injiziert Postfix-Null-Byte(s), gefolgt von einem Backslash, um zu beobachten, wie die Anwendung sie als Eingabe verarbeitet. Der Angreifer sucht nach Bereichen, in denen die Benutzereingabe in der Mitte einer Zeichenkette platziert ist, und das Null-Byte veranlasst die Anwendung, die Verarbeitung der Zeichenkette am Ende der Benutzereingabe zu beenden. [Daten nach dem/den Null-Byte(s) entfernen] Nachdem der Angreifer die verwundbaren Einstiegspunkte ermittelt hat, platziert er ein oder mehrere Null-Byte(s), gefolgt von einem Backslash, so dass er einen Eingabefilter umgeht und Daten nach dem/den Null-Byte(s) auf eine für ihn vorteilhafte Weise entfernt.

Bei dieser Art von Angriff handelt es sich um eine Form von Cross-Site Scripting (XSS), bei der ein bösartiges Skript in das von einem Webbrowser geparste clientseitige HTML eingefügt wird. Der von einer anfälligen Webanwendung bereitgestellte Inhalt enthält Skriptcode, der zur Manipulation des Document Object Model (DOM) verwendet wird. Dieser Skriptcode überprüft entweder die Eingaben nicht ordnungsgemäß oder führt keine ordnungsgemäße Ausgabecodierung durch, so dass ein Angreifer die Möglichkeit hat, ein bösartiges Skript einzufügen und einen XSS-Angriff zu starten. Ein wichtiger Unterschied zwischen anderen XSS-Angriffen und DOM-basierten Angriffen besteht darin, dass bei anderen XSS-Angriffen das bösartige Skript beim ersten Laden der anfälligen Webseite ausgeführt wird, während ein DOM-basierter Angriff irgendwann nach dem Laden der Seite ausgeführt wird. Ein weiteres Unterscheidungsmerkmal von DOM-basierten Angriffen ist, dass in einigen Fällen das bösartige Skript überhaupt nicht an den anfälligen Webserver gesendet wird. Ein solcher Angriff umgeht garantiert alle serverseitigen Filterungsversuche zum Schutz der Benutzer. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, Formulare, aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene gängige Skript-Nutzlasten und Sonderzeichen, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Sicherheitslücke darstellt, und um das Ausmaß zu charakterisieren, in dem die Sicherheitslücke ausgenutzt werden kann. Speziell bei DOM-basiertem XSS sucht der Angreifer nach Bereichen, in denen Eingaben verwendet werden, um das DOM direkt zu verändern. [Sobald der Angreifer ermittelt hat, welche Parameter für XSS anfällig sind, erstellt er eine bösartige URL, die den XSS-Exploit enthält. Der Angreifer kann viele Ziele verfolgen, z. B. den Diebstahl von Sitzungs-IDs, Cookies, Anmeldedaten und Seiteninhalten des Opfers. Bei DOM-basiertem XSS wird das bösartige Skript möglicherweise nicht einmal an den Server gesendet, da der Browser des Opfers das DOM selbst manipuliert. Dies kann dazu beitragen, serverseitige Erkennungsmechanismen zu umgehen. [Damit der Angriff erfolgreich ist, muss das Opfer auf die bösartige URL zugreifen.

Ein Angreifer bettet bösartige Skripte in Inhalte ein, die den Webbrowsern angezeigt werden sollen. Ziel des Angriffs ist es, dass die Zielsoftware, der clientseitige Browser, das Skript mit der Berechtigungsstufe des Benutzers ausführt. Ein Angriff dieser Art nutzt die Schwachstellen eines Programms aus, die dadurch entstehen, dass Remote-Hosts Code und Skripte ausführen können. Webbrowser verfügen beispielsweise über einige einfache Sicherheitskontrollen, aber wenn ein Angreifer Skripte ausführen kann (indem er sie in benutzergenerierte Inhalte wie Bulletin Boards einschleust), können diese Kontrollen umgangen werden. Außerdem sind diese Angriffe für einen Endbenutzer sehr schwer zu erkennen. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, Formulare, aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene gängige Skript-Nutzlasten, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Sicherheitslücke darstellt, und um das Ausmaß zu charakterisieren, in dem die Sicherheitslücke ausgenutzt werden kann. [Stehlen von Sitzungs-IDs, Anmeldedaten, Seiteninhalten usw.] Wenn es dem Angreifer gelingt, die Schwachstelle auszunutzen, kann er die Anmeldedaten des Benutzers stehlen, um sie später wieder zu verwenden oder zu analysieren. [Forceful Browsing] Wenn der Angreifer auf die aktuelle Anwendung oder eine andere Anwendung abzielt (durch CSRF-Schwachstellen), führt der Benutzer die Angriffe aus, ohne sich dessen bewusst zu sein. Diese Angriffe zielen meist auf Fehler in der Anwendungslogik ab, können aber auch dazu verwendet werden, einen weitreichenden Angriff gegen eine bestimmte Website im aktuellen Netzwerk des Benutzers (Internet oder nicht) zu starten. (Content Spoofing) Durch Manipulation des Inhalts zielt der Angreifer auf die Informationen ab, die der Benutzer von der Website erhalten möchte.

Dieser Angriff zielt auf die Kodierung der URL in Kombination mit der Kodierung der Slash-Zeichen. Ein Angreifer kann die vielfältigen Möglichkeiten der Kodierung einer URL ausnutzen und die Interpretation der URL missbrauchen. Eine URL kann Sonderzeichen enthalten, die eine spezielle Syntaxbehandlung benötigen, um interpretiert zu werden. Sonderzeichen werden durch ein Prozentzeichen dargestellt, gefolgt von zwei Ziffern, die den Oktettcode des ursprünglichen Zeichens darstellen (%HEX-CODE). Zum Beispiel würde das US-ASCII-Leerzeichen mit %20 dargestellt werden. Dies wird oft als "escaped ending" oder "percent-encoding" bezeichnet. Da der Server die URL aus den Anfragen dekodiert, kann er den Zugriff auf einige URL-Pfade einschränken, indem er die empfangenen URL-Anfragen validiert und herausfiltert. Ein Angreifer wird versuchen, eine URL mit einer Folge von Sonderzeichen zu erstellen, die, sobald sie vom Server interpretiert wird, einer verbotenen URL entspricht. Es kann schwierig sein, sich gegen diesen Angriff zu schützen, da die URL andere Kodierungsformate wie UTF-8-Kodierung, Unicode-Kodierung usw. enthalten kann. Der Angreifer greift über eine bestimmte URL auf den Server zu. Der Angreifer versucht, einige Sonderzeichen in der URL zu kodieren. Der Angreifer stellt fest, dass einige Zeichen nicht richtig gefiltert werden. Der Angreifer bastelt eine bösartige URL-String-Anforderung und sendet sie an den Server. Der Server dekodiert und interpretiert den URL-String. Da die Eingabefilterung nicht ordnungsgemäß durchgeführt wird, haben die Sonderzeichen leider schädliche Folgen.

[Zielanwendung finden] Ziel-Webanwendung finden, die eine Benutzereingabe akzeptiert und Daten vom Server abruft [Vorhandene Anwendungsanfragen untersuchen] HTTP/GET-Anfragen untersuchen, um das URL-Abfrageformat zu sehen. Angreifer testen, ob diese Art von Angriff durch Schwachstellen im Schutz einer Anwendung vor Server Side Request Forgery möglich ist [Bösartige Anfrage] Der Angreifer erstellt eine bösartige URL-Anfrage, die die Berechtigungsstufe des Servers annimmt, um interne oder externe Netzwerkdienste abzufragen, und sendet die Anfrage an die Anwendung.

Dieser Angriff zielt auf Anwendungen und Software, die die Funktion syslog() unsicher verwenden. Wenn eine Anwendung nicht explizit einen Format-String-Parameter in einem Aufruf von syslog() verwendet, können Benutzereingaben in den Format-String-Parameter eingefügt werden, was zu einem Format-String-Injection-Angriff führt. Angreifer können dann bösartige Format-String-Befehle in den Funktionsaufruf einschleusen, was zu einem Pufferüberlauf führt. Es gibt viele gemeldete Software-Schwachstellen, deren Hauptursache ein Missbrauch der Funktion syslog() ist. [Zielanwendung identifizieren] Der Angreifer identifiziert eine Zielanwendung oder ein Zielprogramm, um den Pufferüberlauf auszuführen. Bei diesem Angriff suchen die Angreifer nach Anwendungen, die syslog() fehlerhaft verwenden. [Injektionsvektor finden] Der Angreifer identifiziert einen Injektionsvektor, um den übermäßigen Inhalt in den Puffer der Zielanwendung zu übertragen. Für jede vom Benutzer kontrollierbare Eingabe, von der der Angreifer vermutet, dass sie für die Injektion von Format-Strings anfällig ist, versucht er, Formatierungszeichen wie %n, %s usw. zu injizieren. Ziel ist es, die Zeichenkettenerstellung mit diesen Formatierungszeichen zu manipulieren. [Craft overflow content] Der Angreifer bastelt den Inhalt, der injiziert werden soll. Wenn die Absicht darin besteht, die Software einfach zum Absturz zu bringen, muss der Inhalt nur aus einer übermäßigen Menge an Zufallsdaten bestehen. Wenn die Absicht darin besteht, den Überlauf zur Ausführung von beliebigem Code zu nutzen, stellt der Angreifer eine Reihe von Inhalten her, die nicht nur den Zielpuffer überlaufen lassen, sondern dies auch so tun, dass die überschriebene Rücksprungadresse durch eine vom Angreifer gewählte Adresse ersetzt wird, die auf vom Angreifer eingeschleusten Code verweist. [Überlauf des Puffers] Mit Hilfe des Injektionsvektors versorgt der Angreifer das Programm mit der manipulierten Format-String-Injektion und verursacht einen Pufferüberlauf.

Blind SQL Injection resultiert aus einer unzureichenden Mitigation für SQL Injection. Obwohl die Unterdrückung von Datenbank-Fehlermeldungen als Best Practice gilt, ist die Unterdrückung allein nicht ausreichend, um SQL Injection zu verhindern. Blind SQL Injection ist eine Form der SQL Injection, die das Fehlen von Fehlermeldungen überwindet. Ohne die Fehlermeldungen, die SQL Injection erleichtern, konstruiert der Angreifer Eingabestrings, die das Ziel durch einfache boolesche SQL-Ausdrücke abfragen. Der Angreifer kann anhand der Ausführung der Abfrage feststellen, ob die Syntax und Struktur der Injektion erfolgreich war oder nicht. Iterativ angewandt, bestimmt der Angreifer, wie und wo das Ziel für SQL Injection anfällig ist. [Hypothesen zu SQL-Abfragen in der Anwendung aufstellen] [Bestimmen, wie Informationen in die Abfragen injiziert werden können] [Vom Benutzer steuerbare Eingaben bestimmen, die für Injektionen anfällig sind] Bestimmen Sie die vom Benutzer steuerbaren Eingaben, die für Injektionen anfällig sind. Versuchen Sie für jede benutzerkontrollierbare Eingabe, von der der Angreifer vermutet, dass sie für SQL-Injection anfällig ist, die im vorherigen Schritt ermittelten Werte zu injizieren. Wenn kein Fehler auftritt, weiß der Angreifer, dass die SQL-Injektion erfolgreich war. Datenbanktyp ermitteln] Ermittelt den Typ der Datenbank, z. B. MS SQL Server oder Oracle oder MySQL, mithilfe logischer Bedingungen als Teil der injizierten Abfragen [Informationen über das Datenbankschema extrahieren] Extrahiert Informationen über das Datenbankschema, indem er die Datenbank dazu bringt, Ja/Nein-Fragen über das Schema zu beantworten. SQL-Injection-Schwachstelle ausnutzen] Verwenden Sie die in den vorherigen Schritten erhaltenen Informationen, um die Datenbank erfolgreich zu injizieren, um Prüfungen zu umgehen oder Daten in der Datenbank zu ändern, hinzuzufügen, abzurufen oder zu löschen.

Ein Angreifer könnte eine Unicode-Zeichenfolge an eine Systemkomponente übermitteln, die nicht Unicode-fähig ist, und dies nutzen, um den Filter zu umgehen oder den Klassifizierungsmechanismus dazu zu bringen, die Anfrage nicht richtig zu verstehen. Dadurch kann der Angreifer bösartige Daten am Inhaltsfilter vorbeischleusen und/oder die Anwendung veranlassen, die Anfrage falsch weiterzuleiten. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, die Formulare, die aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene Unicode-kodierte Nutzdaten, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Schwachstelle mit unzureichender Validierungslogik darstellt, und um das Ausmaß zu charakterisieren, in dem die Schwachstelle ausgenutzt werden kann.

Dieser Angriff zielt auf die Kodierung der URL ab. Ein Angreifer kann die mehrfache Kodierung einer URL ausnutzen und die Interpretation der URL missbrauchen. [Webanwendung auf URLs mit Parametern untersuchen] Mithilfe eines Browsers, eines automatisierten Tools oder durch Inspektion der Anwendung erfasst ein Angreifer alle URLs, die Parameter enthalten. [URLs untersuchen, um Schwachstellen zu finden] Der Angreifer verwendet die in der "Erkundungsphase" gesammelten URLs als Zielliste und testet Parameter mit verschiedenen Kodierungen von Sonderzeichen, um zu sehen, wie die Webanwendung damit umgeht. [Einfügen von Sonderzeichen in URL-Parameter] Anhand der in der "Experiment"-Phase gesammelten Informationen fügt der Angreifer mithilfe der URL-Kodierung Sonderzeichen in die URL ein. Dies kann zu Pfadüberquerungen, Cross-Site-Scripting, SQL-Injection usw. führen.

Bei einem Angriff dieser Art fügt ein Angreifer direkt oder indirekt bösartige Zeichen (z. B. eine XSS-Umleitung) in einen Dateinamen ein, der dann von der Zielsoftware verwendet wird, um HTML-Text oder andere potenziell ausführbare Inhalte zu erzeugen. Viele Websites verlassen sich auf benutzergenerierte Inhalte und bauen Ressourcen wie Dateien, Dateinamen und URL-Links dynamisch direkt aus den vom Benutzer bereitgestellten Daten auf. Bei diesem Angriffsmuster lädt der Angreifer Code hoch, der im Client-Browser ausgeführt werden kann und/oder den Client-Browser auf eine Website umleitet, die dem Angreifer gehört. Alle XSS-Angriffsvarianten können verwendet werden, um diese Schwachstellen zu passieren und auszunutzen.

Dieser Angriff zielt auf die Verwendung des Backslashs in der alternativen Kodierung ab. Ein Angreifer kann einen Backslash als führendes Zeichen vorgeben und einen Parser dazu bringen, zu glauben, dass das nächste Zeichen ein Sonderzeichen ist. Dies wird als Escape bezeichnet. Mit diesem Trick versucht der Angreifer, alternative Möglichkeiten zur Kodierung desselben Zeichens auszunutzen, was zu Filterproblemen führt und Möglichkeiten für Angriffe eröffnet. [Untersuchung der Anwendung auf benutzergesteuerte Eingaben] Mithilfe eines Browsers, eines automatisierten Tools oder durch Inspektion der Anwendung erfasst ein Angreifer alle Einstiegspunkte in die Anwendung. [Eingangspunkte untersuchen, um Schwachstellen zu finden] Der Angreifer verwendet die in der "Erkundungsphase" gesammelten Eingangspunkte als Zielliste und versucht, mehrere verschiedene Sonderzeichen mit einem Backslash zu umgehen. [Eingabe manipulieren] Sobald der Angreifer herausgefunden hat, wie er Filter, die Sonderzeichen herausfiltern, mit einem umgekehrten Schrägstrich umgehen kann, manipuliert er die Benutzereingabe auf eine Weise, die von der Anwendung nicht beabsichtigt ist.

Dieser Angriff zielt auf die Kodierung der Slash-Zeichen ab. Ein Angreifer würde versuchen, gängige Filterprobleme im Zusammenhang mit der Verwendung von Schrägstrich-Zeichen auszunutzen, um Zugriff auf Ressourcen auf dem Zielhost zu erhalten. Verzeichnisgesteuerte Systeme wie Dateisysteme und Datenbanken verwenden in der Regel das Schrägstrich-Zeichen, um den Durchgang zwischen Verzeichnissen oder anderen Container-Komponenten anzuzeigen. Aus unerfindlichen historischen Gründen verwenden PCs (und infolgedessen auch Microsoft-Betriebssysteme) einen Backslash, während in der UNIX-Welt in der Regel der Schrägstrich verwendet wird. Das schizophrene Ergebnis ist, dass viele MS-basierte Systeme beide Formen des Schrägstrichs verstehen müssen. Dies gibt dem Angreifer viele Möglichkeiten, eine Reihe von gängigen Filterproblemen zu entdecken und zu missbrauchen. Ziel dieses Musters ist es, Serversoftware zu entdecken, die nur auf eine Version Filter anwendet, aber nicht auf die andere. [Mit Hilfe eines Browsers, eines automatisierten Tools oder durch Inspektion der Anwendung zeichnet ein Angreifer alle Eingangspunkte zur Anwendung auf. [Der Angreifer verwendet die in der Erkundungsphase erfassten Einstiegspunkte als Zielliste und sucht nach Bereichen, in denen Benutzereingaben verwendet werden, um auf Ressourcen des Zielhosts zuzugreifen. Der Angreifer versucht verschiedene Kodierungen von Schrägstrichzeichen, um Eingabefilter zu umgehen. [Sobald der Angreifer herausgefunden hat, wie er Filter, die Schrägstriche herausfiltern, umgehen kann, manipuliert er die Benutzereingabe so, dass sie Schrägstriche enthält, um Verzeichnisse zu durchsuchen und auf Ressourcen zuzugreifen, die nicht für den Benutzer bestimmt sind.

Dieser Angriff zielt auf Bibliotheken oder gemeinsam genutzte Code-Module ab, die für Pufferüberlauf-Angriffe anfällig sind. Ein Angreifer, der Kenntnis von bekannten anfälligen Bibliotheken oder gemeinsam genutztem Code hat, kann leicht Software angreifen, die diese Bibliotheken nutzt. Alle Clients, die die Code-Bibliothek nutzen, werden dadurch angreifbar. Dies hat sehr weitreichende Auswirkungen auf die Sicherheit eines Systems und betrifft in der Regel mehr als einen Softwareprozess. [Identifizieren der Zielanwendung] Der Angreifer kennt die anfälligen Bibliotheken oder gemeinsam genutzten Code-Module und identifiziert eine Zielanwendung oder ein Programm, das diese nutzt. [Injektionsvektor finden] Der Angreifer versucht, die API zu verwenden, und wenn er kann, sendet er eine große Menge an Daten, um zu sehen, ob der Pufferüberlauf-Angriff wirklich funktioniert. [Craft overflow content] Der Angreifer stellt den zu injizierenden Inhalt auf der Grundlage seines Wissens über die Sicherheitslücke und des gewünschten Ergebnisses zusammen. Wenn die Absicht darin besteht, die Software einfach zum Absturz zu bringen, muss der Inhalt nur aus einer übermäßigen Menge an Zufallsdaten bestehen. Wenn die Absicht darin besteht, den Überlauf für die Ausführung von beliebigem Code zu nutzen, wird der Angreifer eine Reihe von Inhalten erstellen, die nicht nur den Zielpuffer überlaufen lassen, sondern dies auch so tun, dass die überschriebene Rücksprungadresse durch eine vom Angreifer gewählte Adresse ersetzt wird, die auf vom Angreifer eingeschleusten Code verweist. [Überlauf des Puffers] Unter Verwendung der API als Injektionsvektor injiziert der Angreifer den erstellten Überlaufinhalt in den Puffer.

Bei diesem Angriff handelt es sich um eine spezielle Variante der Ausnutzung alternativer Kodierungen zur Umgehung der Validierungslogik. Dieser Angriff nutzt die Möglichkeit, potenziell schädliche Eingaben in UTF-8 zu kodieren und sie an Anwendungen zu übermitteln, die diesen Kodierungsstandard nicht erwarten oder nicht effektiv validieren können, was die Filterung von Eingaben erschwert. UTF-8 (8-bit UCS/Unicode Transformation Format) ist eine Zeichenkodierung mit variabler Länge für Unicode. Legale UTF-8-Zeichen sind ein bis vier Byte lang. In einer frühen Version der UTF-8-Spezifikation waren jedoch einige Einträge falsch (in einigen Fällen wurden überlange Zeichen zugelassen). UTF-8-Kodierer sollen die "kürzestmögliche" Kodierung verwenden, aber naive Dekodierer können Kodierungen akzeptieren, die länger als nötig sind. Laut RFC 3629 kann eine besonders subtile Form dieses Angriffs gegen einen Parser durchgeführt werden, der sicherheitskritische Gültigkeitsprüfungen gegen die UTF-8-kodierte Form seiner Eingabe durchführt, aber bestimmte illegale Oktettfolgen als Zeichen interpretiert. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, die Formulare, die aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene UTF-8-kodierte Nutzdaten, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Sicherheitslücke mit unzureichender Validierungslogik darstellt, und um das Ausmaß zu charakterisieren, in dem die Sicherheitslücke ausgenutzt werden kann.

Bei Angriffen zur Manipulation von Webprotokollen fügt ein Angreifer den Inhalt von Webprotokollen ein, löscht ihn oder manipuliert ihn auf andere Weise, in der Regel um andere bösartige Handlungen zu verschleiern. Darüber hinaus kann das Schreiben bösartiger Daten in Protokolldateien auf Jobs, Filter, Berichte und andere Agenten abzielen, die die Protokolle in einem asynchronen Angriffsmuster verarbeiten. Dieses Angriffsmuster ähnelt dem "Log Injection-Tampering-Forging", nur dass in diesem Fall der Angriff auf die Protokolle des Webservers und nicht auf die Anwendung abzielt. [Der Angreifer beobachtet das System und sucht nach Indikatoren dafür, welches Protokollierungsprogramm vom Webserver verwendet wird. [Injectable Content] Der Angreifer startet verschiedene protokollierte Aktionen mit bösartigen Daten, um festzustellen, welche Art von Log-Injection möglich ist. [Manipulation von Protokolldateien] Der Angreifer verändert die Protokollinhalte entweder direkt durch Manipulation oder Fälschung oder indirekt durch Einspeisung speziell gestalteter Anfragen, die der Webserver empfängt und in die Protokolle schreibt. Diese Art von Angriff folgt in der Regel auf einen anderen Angriff und wird verwendet, um die Spuren des vorherigen Angriffs zu verwischen.

Ein Angreifer kann spezielle, vom Benutzer kontrollierbare Eingaben machen, die aus XPath-Ausdrücken bestehen, um die XML-Datenbank zu infiltrieren und die Authentifizierung zu umgehen oder Informationen zu sammeln, die er normalerweise nicht bekommen würde. XPath Injection ermöglicht es einem Angreifer, direkt mit der XML-Datenbank zu kommunizieren und so die Anwendung vollständig zu umgehen. XPath Injection entsteht, wenn eine Anwendung Eingaben, die als Teil von dynamischen XPath-Ausdrücken zur Abfrage einer XML-Datenbank verwendet werden, nicht ordnungsgemäß bereinigt. [Mit Hilfe eines Browsers oder eines automatisierten Tools zeichnet ein Angreifer alle Instanzen der vom Benutzer kontrollierbaren Eingaben auf, die zur Erstellung von XPath-Abfragen verwendet werden. [Struktur der Abfragen ermitteln] Mit manuellen oder automatisierten Mitteln testen Sie die gefundenen Eingaben auf XPath-Schwachstellen. [Einschleusen von Inhalten in XPath-Abfragen] Erstellen bösartiger Inhalte mit XPath-Ausdrücken, die von der Anwendung nicht validiert und als Teil der XPath-Abfragen ausgeführt werden.

Dieser Angriff nutzt die häufigen Client-Server-Roundtrips in Ajax-Konversationen, um ein System zu scannen. Ajax eröffnet zwar nicht per se neue Schwachstellen, optimiert sie aber aus Sicht des Angreifers. Ein üblicher erster Schritt für einen Angreifer ist die Erstellung eines Footprints der Zielumgebung, um zu verstehen, welche Angriffe funktionieren werden. Da das Footprinting auf einer Aufzählung beruht, kann ein Angreifer aufgrund des für Ajax-Anwendungen typischen Konversationsmusters aus schnellen, mehrfachen Anfragen und Antworten nach vielen Schwachstellen, bekannten Ports, Netzwerkstandorten usw. suchen. Das durch Ajax-Fingerprinting gewonnene Wissen kann zur Unterstützung anderer Angriffe wie XSS verwendet werden. [Mit Hilfe eines Browsers oder eines automatisierten Tools sendet ein Angreifer Anfragen an eine Webseite und zeichnet die empfangene HTML-Antwort auf. Die Angreifer analysieren dann den HTML-Code, um alle bekannten zugrunde liegenden JavaScript-Architekturen zu identifizieren. Dies kann dabei helfen, öffentlich bekannte Schwachstellen der Webseite zuzuordnen, und es kann dem Angreifer auch helfen, die Anwendungsarchitektur und die innere Funktionsweise eines Systems zu erraten.

Bei dieser Art eines Angriffs injiziert ein Angreifer Betriebssystembefehle in bestehende Anwendungsfunktionen. Eine Anwendung, die nicht vertrauenswürdige Eingaben zum Aufbau von Befehlsstrings verwendet, ist anfällig. Ein Angreifer kann die Injektion von Betriebssystembefehlen in eine Anwendung ausnutzen, um die Berechtigungen zu erhöhen, beliebige Befehle auszuführen und das zugrunde liegende Betriebssystem zu kompromittieren. [Identifizieren von Eingaben für Betriebssystembefehle] Der Angreifer ermittelt die vom Benutzer kontrollierbaren Eingaben, die als Teil eines Befehls an das zugrunde liegende Betriebssystem weitergegeben werden. Die Anwendung untersuchen] Der Angreifer untersucht die Zielanwendung, möglicherweise als gültiger und authentifizierter Benutzer [Eingaben variieren, nach bösartigen Ergebnissen suchen] Je nachdem, ob es sich bei der auszunutzenden Anwendung um eine entfernte oder lokale Anwendung handelt, bastelt der Angreifer die entsprechenden bösartigen Eingaben, die Betriebssystembefehle enthalten, die an die Anwendung weitergegeben werden sollen [Bösartige Befehle ausführen] Der Angreifer kann Informationen stehlen, einen Hintertür-Zugangsmechanismus installieren, die Berechtigungen erhöhen oder das System auf andere Weise kompromittieren.

Dieser Angriff zielt auf Befehlszeilen-Dienstprogramme ab, die in einer Reihe von Shells verfügbar sind. Ein Angreifer kann eine in einem Befehlszeilendienstprogramm gefundene Schwachstelle ausnutzen, um die Rechte auf root zu erweitern. [Zielsystem identifizieren] Der Angreifer sucht sich zunächst ein Zielsystem, auf dem er erhöhte Rechte erlangen möchte. Dabei kann es sich um ein System handeln, auf das er bereits in gewissem Umfang Zugriff hat, oder um ein System, auf das er sich auf andere Weise unberechtigten Zugriff mit niedrigeren Rechten verschaffen will. [Injektionsvektor finden] Der Angreifer identifiziert Befehlszeilendienstprogramme, die vom Zielhost bereitgestellt werden und Pufferüberlaufschwachstellen enthalten. Der Angreifer weiß wahrscheinlich, welche Dienstprogramme diese Schwachstellen aufweisen und welche Versionen davon betroffen sind. [Sobald der Angreifer ein anfälliges Dienstprogramm gefunden hat, nutzt er seine Kenntnisse über die Schwachstelle, um den Befehl zu erstellen, mit dem der Pufferüberlauf ausgenutzt werden kann. [Überlauf des Puffers] Mithilfe des Injektionsvektors führt der Angreifer den erstellten Befehl aus und erlangt erweiterte Rechte auf dem Computer.