it-swarm.com.de

Wie stark sollte ich versuchen, einen Benutzer daran zu hindern, sich selbst zu XSSen?

Angenommen, ein Benutzer kann einige Daten in einer Web-App speichern. Ich spreche jetzt nur über diese Art von Daten, die der Benutzer selbst anzeigen kann, und nicht über die, die von anderen Benutzern der Webanwendung angezeigt werden sollen. (Wenn andere Benutzer diese Daten anzeigen, werden sie sicherer behandelt.)

Wie schrecklich wäre es, eine XSS-Sicherheitslücke in diesen Daten zuzulassen?

Die Antwort eines Puristen wäre natürlich eindeutig: "Keine Schwachstellen sind erlaubt". Aber ehrlich - warum?

Alles, was erlaubt ist, ist der Benutzer XSSing THEMSELVES. Was ist der Schaden hier? Andere Benutzer sind geschützt. Und ich kann keinen Grund erkennen, warum jemand einen Angriff gegen sich selbst starten würde (außer wenn es harmlos ist, in welchem ​​Fall - wieder - kein Schaden angerichtet wird).

Mein Bauchgefühl ist, dass die obige Argumentation einige Augenbrauen hochziehen wird ... OK, was sehe ich dann nicht?

60
gaazkam

Dies ist eigentlich ein echtes Konzept, "Self XSS", das so häufig vorkommt, dass Sie beim Öffnen von https://facebook.com und anschließendem Öffnen der Entwicklertools gewarnt werden as shown here

Offensichtlich ist Facebook eine bestimmte Art von Ziel und ob dieses Problem für Sie von Bedeutung ist oder nicht, hängt von der genauen Art Ihrer Website ab. Möglicherweise können Sie jedoch die Idee eines Benutzers, der Social-Engineering-Techniken verwendet, um einen anderen Benutzer dazu zu bewegen, nicht ignorieren sich selbst angreifen.

107
Rory McCune

Obwohl Sie darin Recht haben, ist es aus Angriffssicht möglicherweise nicht so wichtig. Unter dem Gesichtspunkt der Benutzerfreundlichkeit kann der Benutzer auf ein 'nerwartetes Verhalten' stoßen. Vor einiger Zeit musste ich mit Software arbeiten, die ein offensichtliches SQL-Injection-Problem hatte (Auftragnehmer konnten/wollten es nicht beheben). Dies bedeutete, dass unerwartete Benutzer etwas scheinbar Unschädliches wie ihren Namen "O'Brien" eingeben würden, das eine SQL-Injection auslösen würde, und für Computer-Analphabeten war es unerwartetes Verhalten, das für sie äußerst schwierig zu beheben war. Bei XSS ist dies wahrscheinlich weniger wahrscheinlich. Beachten Sie jedoch Folgendes, wenn ein Benutzer <> anstelle von () verwendet, scheinen die Daten möglicherweise zu verschwinden. Ein Proof of Concept ist unten:

<html>
    <head><title>HI</title></head>
    <body>
        <h1>WEBSITE</h1>
        Hey my name is <travis>.
    </body>
</html>

Beachten Sie, dass beim Rendern dieser Website das Wort 'travis' nicht gerendert wird.

39
meowcat

Wenn die einzige Möglichkeit, schädlichen Code einzufügen, darin besteht, ihn buchstäblich auf Ihrer Webseite einzugeben, lautet der Angriffsvektor "self xss", der in einer anderen Antwort erwähnt wurde und ein Social-Engineering-Angriff ist, den Sie nicht wirklich verhindern können.

Wenn bösartiger Code jedoch auch auf andere Weise auf Ihre Seite geladen werden kann, haben Sie ein größeres Problem. Wenn Ihre Website beispielsweise für reflektiertes XSS oder CSRF anfällig ist, kann ein Angreifer diese verwenden, um den Benutzer dazu zu bringen, schädlichen Code zu laden.

Beispiel für reflektiertes XSS: Wenn der Datenparameter auf der Seite gedruckt wird, ohne ihn zu bereinigen, kann ein Angreifer das Opfer dazu bringen, zur folgenden URL zu navigieren, damit es bösartigen Code lädt.

https://www.example.com/search?data=<script src="..."></script>

Beispiel für CSRF: Wenn die übermittelten Daten dann auf der Seite gedruckt werden, ohne sie zu bereinigen, und es auch keinen Schutz gegen CSRF gibt, kann ein Angreifer das Opfer dazu bringen, böswillige Daten zu veröffentlichen.

<form method="post" action="submit">
    <input type="text" name="title">
    <input type="text" name="note">
    <input type="submit" value="submit">
    <!-- NO TOKEN TO PREVENT CSRF HERE!!! -->
</form>

Wie Sie sehen, ist das Problem nicht nur "wer kann die Daten sehen", sondern auch "wer kann die Daten eingeben". Aber selbst wenn Sie sicher waren, dass die obigen Beispiele nicht auf Ihre Situation zutreffen, warum sollten Sie dennoch versuchen, XSS zu vermeiden und immer zu versuchen, die Daten zu bereinigen? Weil Desinfektion zur Gewohnheit werden sollte, auch wenn sie in manchen Situationen nicht wirklich nützlich erscheint. Wenn Desinfektion keine Gewohnheit ist, werden Sie früher oder später vergessen, etwas zu desinfizieren, das schließlich zu XSS führt.

18
reed

XSS ist immer noch schlecht, auch wenn die Nutzdaten an das Konto gebunden sind, mit dem es erstellt wurde. Sicher, es ist nicht so schlimm wie "gewöhnliches" XSS, aber es ist immer noch nicht harmlos.

Hier ist ein Beispiel für einen Angriff: Zuerst muss ich das Opfer dazu bringen, sich als ich anzumelden. Dies kann durch Social Engineering oder Login CSRF erfolgen, wenn kein Schutz dagegen besteht. Zweitens muss das Opfer die betroffene Seite besuchen, die als ich angemeldet ist. Das Skript fügt der Site dann einen Keylogger hinzu. Wenn sich das Opfer abmeldet und versucht, sich als sich selbst anzumelden, wird mir das Kennwort gesendet.

Es gibt viele Gründe, warum ein solcher Angriff fehlschlagen würde, aber es könnte einfach funktionieren. Sie sollten alle XSS-Löcher verschließen, egal wo sie sich befinden.

13
Anders

Ich denke, es gibt einen anderen Anwendungsfall, der in den Antworten bisher möglicherweise nicht aufgeführt ist, nämlich versehentlich self XSS. Einige Benutzer stoßen möglicherweise auf ein Problem, das auf einer Website auftritt, und suchen möglicherweise nach Drop-In-Lösungen, die sie kopieren und einfügen. Sorgfältig ausgearbeitete "Lösungen" können Probleme verursachen.

Der Umfang des Angriffs besteht darin, dass sich der Benutzer versehentlich selbst verletzt, andere Benutzer jedoch wahrscheinlich nicht schädigen. Dies ähnelt dem gefährlichen Kopieren und Einfügen von Bash-Befehlen, die Sie im Internet finden. Eine böswillige Site bietet möglicherweise Linux-Hilfe, enthält jedoch auf subtile Weise einen Befehl, mit dem Benutzerdaten auf irgendeine Weise exfiltriert werden können.

6
zero298

Das angebliche Zulassen von "Self-XSS" -Angriffen kann sekundäre Auswirkungen haben.

Als Beispiel habe ich kürzlich ein Problem gesehen, bei dem ein Textfeld laut Fehlerbericht den gesamten Text nach einem weniger als Zeichen entfernen. Der Browser interpretierte das Less-Than-Zeichen als Start eines HTML-Tags.

Ein weiteres Problem, das ich gesehen habe, ist, dass solche "Self-XSS" -Felder keine willkürlich gültige Eingabe zulassen. Stellen Sie sich beispielsweise ein Feld "Notizen" vor, in dem der Benutzer möglicherweise etwas speichern möchte, das er gelernt hat:

One can make bold text by surrounding it with these tags: <b>Hello, bold world!</b>

Wenn Ihre Anwendung "Self-XSS" -Angriffe zulässt, hat der Benutzer Schwierigkeiten, eine solche Notiz hinzuzufügen.

5
dotancohen

Was in anderen Antworten nicht erwähnt wird, sind die potenziellen sekundären Sicherheitsprobleme, die sich aus einem Self-XSS ergeben können.

Angenommen, Ihre App verfügt über einige wirklich leistungsstarke/gefährliche Funktionen, bei denen der Benutzer sein Kennwort erneut eingeben muss, z. B. das Ändern eines alten Kennworts oder das Zugreifen eines Drittanbieters auf sein Konto. Ein Angreifer kann vorübergehend über einen Angriff wie Cookie-Jacking, Leerlaufsitzung (Benutzer von seinem Schreibtisch entfernt) oder eine Cross-Site-Request-Forgery (CSRF) auf das Konto zugreifen. In keinem dieser Fälle kann der Angreifer diese leistungsstarken Aktionen direkt ausführen, da er das Kennwort des Benutzers nicht kennt. Sie könnten jedoch die Self-XSS-Sicherheitsanfälligkeit ausnutzen, um einen sehr überzeugenden Social-Engineering-Angriff durchzuführen, um die Benutzeranmeldeinformationen abzurufen, oder eine XSS-Nutzlast einrichten, um ihnen dauerhaften Zugriff auf das Benutzerkonto zu gewähren (jedes Mal, wenn sich der Benutzer anmeldet).

Im Fall von CSRF kann eine relativ harmlose Aktion in einen mächtigen Angriff umgewandelt werden, indem die CSRF verwendet wird, um ein gespeichertes Self-XSS zu verursachen, das dem Angreifer dann Zugriff auf die Cookies oder die Browsersitzung des Benutzers gewährt. Ich habe diese Angriffskettentechnik tatsächlich mehrmals verwendet, um Entwicklern Schwachstellen aufzuzeigen.

2
shellster

Aus reiner Sicherheitsperspektive gibt es hier einige gute Antworten. Der Selbst-XSS-Winkel ist absolut korrekt, auch wenn der oberste, der sich darauf bezieht, die implizite Verbindung nicht explizit hergestellt hat.

Wenn Leute dazu verleitet werden, Self-XSS-Code in die Entwicklungskonsole zu werfen, warum sollten Sie dann erwarten, dass sie nicht dazu verleitet werden, in ein Eingabeelement in Ihrer Benutzeroberfläche zu fallen?

Einige andere Antworten verbinden dies damit, wie dies zu umfassenderen Problemen führen kann, wenn dies (unweigerlich, wenn jemand zum Selbst-XSSing verleitet wird) zu Kontokompromissen führt.

Ich denke, das sind wahrscheinlich die wichtigsten unmittelbaren Gründe. Aber ich möchte dies immer noch aus einem anderen Blickwinkel ansprechen:

Entwicklungspraktiken: Implikationen des Zulassens von Self-XSS

Angenommen, ein Benutzer kann einige Daten in einer Web-App speichern. Ich spreche jetzt nur über diese Art von Daten, die der Benutzer selbst anzeigen kann, und nicht über die, die von anderen Benutzern der Webanwendung angezeigt werden sollen.

Das Problem mit Ihrer Annahme hier ist, dass davon ausgegangen wird, dass Sie XSS nicht bei allen Ausgaben von vom Benutzer bereitgestellten Daten als Standardpraxis verhindern: idealerweise als Standardausgabemechanismus der Klasse oder Funktion, die zum Abrufen und Ausgeben von Daten verwendet wird, mit Abweichungen Erfordernis eines bestimmten Parameters zur Auswahl der verschiedenen Ausgangsfiltermethode.

Wenn Sie Ihre Anwendung nicht so codiert haben, dass die Standardausgabemethode XSS verhindert (und unterschiedliche Ausgabeziele wie Attribute und Elemente unterschiedliche Methoden für das erfordern, was zulässig ist und was nicht, daher "Standard"), und Es erfordert mehr Aufwand (nicht weniger), um die Ausgabe anzuvisieren, damit (hoffentlich auf der Whitelist, "gereinigt") etwas als natives HTML/etc ... durchlaufen werden kann.

Wie sicher sind Sie, dass Sie keinen Unfall haben werden, bei dem eine Reflexion von Benutzerdaten zurück ins Web XSS nicht außerhalb von nur "Daten, die der Benutzer selbst anzeigen kann" zulässt?

Weil Fehler passieren. Die Leute vergessen Schritte beim Schreiben von Code. Fehler im Training treten auf, wenn wichtige Punkte oder sogar Themen übersehen werden. Einige Leute nicht "RTFM": sogar Entwickler. In Ihrer Anwendungsarchitektur/Ihrem Framework sollte es darum gehen, sicherzustellen, dass der Weg des geringsten Widerstands beim Schreiben von Code ist immer das sicherste Ergebnis, nicht das am wenigsten sichere Ergebnis.

Das mögliche Auftreten von XSS basierend auf Benutzereingaben sollte eine positive Aktion erfordern, eine explizite Auswahl des Entwicklers in Bezug auf jeden Ort, an dem dies auftreten kann, und nicht nur das grundlegende Standardergebnis des Abrufs gespeicherter Benutzerdaten und deren Wiedergabe. Wenn Ihr Code nicht so geschrieben wird, wo er standardmäßig XSS verhindert und einen Überschreibungsparameter erfordert, um diese Ausgabereinigung zu deaktivieren, ist dies ein Zeichen dafür, dass Sie Ihren Prozess neu bewerten müssen.

2
taswyn

Obwohl wir uns in diesem Zusammenhang auf die technischen Konsequenzen von Ermöglichen eines Selbst-XSS konzentrieren, sollten wir auch die Auswirkungen berücksichtigen von so etwas als Unternehmen: Ein Self-XSS kann zu unerwarteten Verhaltensweisen führen (die sich auf die Benutzererfahrung auswirken). Wie sollte sich ein Benutzer fühlen/reagieren, wenn er darauf stößt?

Wenn man bedenkt, dass eine XSS-Sicherheitsanfälligkeit leicht vermeidbar ist, lohnt es sich wirklich, sich darüber keine Sorgen zu machen? Denken Sie nur an mögliche Konsequenzen: geöffnete Support-Tickets, gemeldete Fehler, Unzufriedenheit der Benutzer, ..?

0
n0idea