Cross Site Scripting (XSS)
Erklärung der Sicherheitslücke
Cross-Site Scripting (XSS) (CWE-79)-Angriffe sind eine Art Injektion, bei der bösartige Skripte in ansonsten harmlose und vertrauenswürdige Websites eingeschleust werden. XSS-Angriffe treten auf, wenn ein Angreifer eine Webanwendung verwendet, um Schadcode, im Allgemeinen in Form eines Browser-Side-Scripts, an einen anderen Endbenutzer zu senden.
Der XSS-Fehler tritt auf, wenn:
- Daten gelangen über eine nicht vertrauenswürdige Quelle in eine Webanwendung, am häufigsten über eine Webanfrage.
- Die Daten sind in dynamischen Inhalten enthalten, die an einen Webbenutzer gesendet werden, ohne auf schädliche Inhalte überprüft zu werden.
Es gibt zwei Haupttypen von XSS-Schwachstellen:
1.Reflektierte XSS-Angriffe sind Angriffe, bei denen das injizierte Skript vom Webserver reflektiert wird, beispielsweise in einer Fehlermeldung, einem Suchergebnis oder einer anderen Antwort, die einige oder alle ,als Teil der HTTP-Anfrage an den Server gesendeten Eingaben enthält.
2.Gespeicherte XSS-Angriffe sind solche, bei denen das eingeschleuste Skript dauerhaft auf den Zielservern gespeichert wird, beispielsweise in einer Datenbank.
Empfohlene Sicherheitskontrollen
Gemäß den Empfehlungen von OWASP und MITRE muss der Schutz vor XSS-Anwendungen Folgendes gewährleisten:1.Verstehen Sie den Kontext, in dem die nicht vertrauenswürdigen Daten verwendet werden, und die erwartete Codierung.
2.Nutzen Sie strukturierte Mechanismen, die automatisch die Trennung zwischen Daten und Code erzwingen. Diese Mechanismen sind möglicherweise in der Lage, die relevanten Zitate, Codierungen und Validierungen automatisch bereitzustellen, anstatt sich darauf zu verlassen, dass der Entwickler diese Funktion an jedem Punkt bereitstellt, an dem die Ausgabe generiert wird.
So funktioniert der Schutz von Waratek
Waratek bietet Schutz vor XSS-Angriffen über die xss-Funktion in der ARMR-HTTP-Regel. Diese Regel verwendet die Tainting-Engine, um alle Benutzereingaben zu verfolgen, stellt eine Verbindung zur Servlet-API der Webanwendung her und überwacht alle Schreibvorgänge für die HTTP-Antwort. Wenn ein Servlet-Schreibvorgang stattfindet, verwendet der Waratek-Agent einen durch Streaming beschädigten HTML 5.0-Lexer und prüft, ob eine Folge benutzersteuerbarer (modifizierter) Zeichen die HTML-Syntax verändert.
Standardmäßig führt die XSS-Regel Folgendes aus:
1.Nur vor reflektierten XSS-Angriffen schützen (d. h. Nutzlasten, die von HTTP-Anfragen stammen)2.Schützen Sie die HTTP-Antworten aller HTTP-Endpunkte, die HTML-Antworten erzeugen
Um den Schutz vor gespeicherten XSS-Angriffen zu ermöglichen, muss die Eingabedeklaration in der ARMR-HTTP-Regel mit dem Wert „Datenbank“ konfiguriert werden. Zum Beispiel: Eingabe(Datenbank)
Um Schutz vor reflektierten und gespeicherten XSS-Angriffen zu ermöglichen, muss die Eingabedeklaration in der ARMR-HTTP-Regel mit den Werten „http“ und „Datenbank“ konfiguriert werden. Zum Beispiel: Eingabe(http, Datenbank)
In den meisten Fällen würde die Definition der oben genannten XSS-Regel das erforderliche Schutzniveau bieten.
Darüber hinaus kann Waratek auch vor Angriffen durch deserialisierte Daten schützen. Beispielsweise aus Protokollen wie RMI, JMX und dem XMLReader, die auf Java- oder XML-Deserialisierung basieren. Um den Schutz vor deserialisierten Nutzlasten zu aktivieren, fügen Sie den Wert „Deserialisierung“ zur Eingabedeklaration in der ARMR-HTTP-Regel hinzu. Zum Beispiel: Eingabe(http, Datenbank, Deserialisierung)
Um die XSS-Sicherheitskontrolle zu aktivieren, kann die Standard-XSS-Regel angegeben werden. In einigen seltenen Fällen müssen Benutzer möglicherweise zusätzliche XSS-Regeln angeben. Dafür gibt es 2 Hauptgründe:
- Eine Anwendung erzeugt möglicherweise HTTP-Antworten, deren Ausgabe HTML ist, deren Inhaltstyp jedoch von der Anwendung falsch festgelegt wurde. Beispielsweise generiert der HTTP-Endpunkt HTML, sein Inhaltstyp ist jedoch XML.
- Für unterschiedliche HTTP-Endpunkte müssen möglicherweise unterschiedliche Taint-Quellen konfiguriert werden.
In solchen Fällen können Benutzer zusätzliche XSS-Regeln definieren und in jeder zusätzlichen XSS-Regel den relativen Pfad des HTTP-Endpunkts angeben, für den XSS-Schutz erzwungen werden muss, sowie optional die Quelle der beschädigten Daten. Zum Beispiel:
app("XSS"):
requires(version: ARMR/2.8)
http("XSS Protection"):
xss(html)
response(paths: "/pathOne")
input(database, deserialization)
protect(message: "XSS attacked identified and blocked", severity: 7)
endhttp
endapp
Abschließend ist es wichtig zu beachten, dass die XSS-Regel standardmäßig in einem nicht strikten Lexing-Modus aktiviert ist. Das bedeutet, dass die XSS-Regel das Einfügen bestimmter Benutzereingaben zulässt (d. h. die HTML-Syntax ändern). Diese bestimmten Eingaben wurden als nicht böswillig überprüft und dienen lediglich der Formatierung. Dadurch können gängige WYSIWYG-Editoren und Auszeichnungssprachen wie Markdown verwendet werden. Diese Funktion wird auch Safe XSS Injection genannt. Um die sichere Injektionsfunktion zu deaktivieren und den strikten Lexing-Modus zu aktivieren, verwenden Sie die Option „policy“ in der XSS-Deklaration. Zum Beispiel: xss(html, Optionen: {policy: strict})
Schutzmaßnahme
Wenn die XSS-Regel im Verweigerungsmodus aktiviert ist und ein XSS-Angriff identifiziert wird, wird der böswillige HTTP-Ausgabevorgang beendet und es ist kein weiteres Schreiben in die HTTP-Antwort zulässig.
Anwendbarkeit der Regel
Die XSS-Regel ist anwendbar und kann sicher für Webanwendungen aktiviert werden, die die Servlet-API zur Verarbeitung von HTTP-Anfragen und -Antworten verwenden.
Empfohlene Vorgehensweise
In den meisten Fällen würde die Definition der folgenden XSS-Regel das erforderliche Schutzniveau bieten.
app("XSS"):
requires(version: ARMR/2.8)
http("XSS Protection"):
response()
xss(html)
input(http, database)
protect(message: "XSS attacked identified and blocked", severity: Very-High)
endhttp
endapp
Weiterführende Verweise:
https://cwe.mitre.org/data/definitions/79.html
https://owasp.org/www-community/attacks/xss/
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html