it-swarm.com.de

Ist reflektiertes XSS heute noch relevant?

Ich habe mehr über XSS gelernt (für Unbekannte ist Excess XSS eine großartige Ressource). Ich entschied mich dafür, meine Hände schmutzig zu machen und Reflected XSS in einer lokalen Umgebung auszuprobieren. Ich habe eine sehr einfache anfällige PHP Seite, die unter Apache2 ausgeführt wird, eingerichtet, die einen URL-Parameter verwendet und den Inhalt auf die Seite kopiert:

<!DOCTYPE html>
<html>
<head>
    <title>VULNERABLE WEBSITE</title>
</head>
<body style="background-color:#98FB98">
    <h1>VULNERABLE WEBSITE</h1>
    <p>Search results for <?php echo $_GET['query']; ?>:</p>
</body>
</html>

Dann habe ich versucht, "bösartiges" JavaScript mithilfe einer URL wie der folgenden in die Seite einzubetten:

http://localhost:8082/?query=<script>alert('Hello!');</script>

Ich fand heraus, dass die Browser selbst dies verhinderten. In Firefox führte mich dies zu einer Google-Suchseite. In Chromium wurde das XSS spezifisch erkannt und blockiert:

(enter image description here

Auf dem Weg von der Theorie zur Praxis frage ich mich jetzt: Ist Reflected XSS heute noch ein relevantes Sicherheitsbedenken?

Dies gilt offensichtlich nicht für Persistent XSS, bei dem der schädliche Inhalt direkt von der Website selbst bereitgestellt wird.

33
Gigi

Reflektiertes XSS ist nicht nur von GET. Es kann durch POST auch sein. Und sie werden nicht immer von den Browsern verhindert. Und natürlich ist immer noch relevant.

Einige Definitionen:

In der Checkmarx-Wissensdatenbank heißt es: " Das am häufigsten gefundene XSS ". Extrahiert aus hier . Also, wenn es das am häufigsten gefundene ist, denke ich, ist es immer noch relevant.

20
OscarAkaElvis

Ja, alle Formen von XSS sind heute noch relevant.

Der bestimmte Angriff, den Sie versucht haben, war für den Browser offensichtlich heuristisch zu finden, aber der Code, der durch subtilere Injektionen generiert wurde, ist möglicherweise nicht vorhanden. Was passiert, wenn ich die Übermittlungs-URL eines Formulars ändere, weil der Entwickler <form action="{$_SERVER['PHP_SELF']}"? Was passiert, wenn ich Ihre Fehlermeldung in eine Bestätigungsmeldung ändere? Was passiert, wenn ich den SHA1-Hash einer heruntergeladenen Linux-Distribution ändere?

Verlassen Sie sich niemals auf clientseitige Funktionen (insbesondere Webbrowser), um Ihren Benutzern Sicherheit zu bieten.

16
dotancohen

Die häufigsten und trivialsten Fälle von reflektiertem XSS - bei denen Sie buchstäblich genau das ausgeben, was bereitgestellt wurde (<?php echo $_GET['query']; ?>) Und es so ausgeführt wird, wie es ist - sind in modernen Browsern standardmäßig nicht relevant, nein.

"Reflected XSS" als Kategorie ist jedoch etwas breiter. Dies schließt auch Fälle ein, in denen die Eingabe auf irgendeine Weise codiert ist. Ein Beispiel, das ich in freier Wildbahn gesehen habe, ist die Reflexion von Base64-codiertem HTML wie <?php echo base64_decode($_GET['query']); ?>. Browserfilter werden das wahrscheinlich nicht erfassen.

Sie müssen auch Fälle berücksichtigen, in denen der Code nicht eigenständig ausgeführt wird, es jedoch ein anderes JavaScript gibt, das dazu führt, dass er später ausgeführt wird. Dies kann am häufigsten in einer clientseitigen Vorlagenbibliothek geschehen, die Ausdrücke in ansonsten statischem Text interpretiert. Betrachten Sie beispielsweise diesen Fall, in dem dyn- - Attribute clientseitig mit einigen Modelldaten ausgewertet werden:

<img dyn-src="model.get('<?php echo $_GET['name']; ?>')" />
<script>
  let model = { something... };
  for (let el of document.querySelectorAll('[dyn-src]')) {
    el.src = eval(el.getAttribute('dyn-src'));
  }
</script>

Dies ermöglicht eine Form von reflektiertem XSS mit so etwas wie ?name=', alert('xss'), ', die Browser wahrscheinlich auch nicht abfangen werden.

9
Jeremy Banks

Reflected XSS ist immer noch relevant, da nicht jeder Browser dieselben Filter auf dieselbe Weise implementiert. Manchmal wird bei einigen Implementierungen ein Bypass entdeckt, sodass der Auditor ihn möglicherweise nicht blockiert.

Einige Websites haben nicht die X-XSS-Protection Header aktiviert, daher sind diese Sites auch anfällig

Und wie in einer anderen Antwort erwähnt, kann die Nutzlast über POST anstelle von GET geliefert werden, wodurch verhindert wird, dass der Prüfer die böswillige Injektion blockiert

Selbst wenn alles korrekt konfiguriert ist und kein Bypass für die Filterimplementierung bekannt ist, handelt es sich nur um einen Filter. Es blockiert bestimmte reflektierte XSS, aber da es falsch positive Ergebnisse gibt, gibt es zu falsch negative, daher bleibt die Nutzlast unentdeckt

5
Mr. E

Ja.

Zum einen verfügt Firefox noch nicht über einen XSS-Filter, sodass reflektierte Angriffe in diesem Browser ausgeführt werden können.

DOM-basiertes XSS umgeht auch Browserfilter. Dies wird nicht streng als "reflektiertes XSS" kategorisiert, das Endergebnis ist jedoch dasselbe.

Beachten Sie außerdem, dass Browser-XSS-Auditoren keine Sicherheitsgrenze darstellen. Von Google :

Nein, XSS-Auditor-Bypässe stellen keine Sicherheitslücken dar Chrome Sicherheitslücken (weshalb dieser Fehler als SecSeverity-None gekennzeichnet ist). Unsere Richtlinien zum Schweregrad finden Sie hier: http://dev.chromium.org/developers/severity-guidelines

Um etwas mehr zu verdeutlichen, ist der XSS-Auditor ein detaillierter Schutzmechanismus, um unsere Benutzer vor einigen häufigen XSS-Schwachstellen auf Websites zu schützen. Wir wissen, dass es nicht alle möglichen XSS-Varianten abfangen kann, und diejenigen, die es abfängt, müssen noch auf der betroffenen Site behoben werden. Der Auditor ist also wirklich ein zusätzliches Sicherheitsnetz für unsere Benutzer, aber nicht als starker Sicherheitsmechanismus gedacht.

In solchen Browsermechanismen gibt es ständig Bypässe. IE Beispiel hier . Und im Gegensatz zu einer anderen Antwort hier versuchen Filter, POST Anfragen auch ) zu blockieren. Sie können dies jedoch Verlassen Sie sich niemals auf diese Filter, um alle XSS zu blockieren.

Das Ergebnis ist, dass Sie XSS in Ihrer Webanwendung durch die Verwendung von Ausgabecodierung, Eingabefilterung/-validierung (falls möglich) und hoffentlich einer strengen Richtlinie zur Inhaltssicherheit verringern sollten.

Das Filtern und Überprüfen von Eingaben kann manchmal schwierig sein. Wenn Sie jedoch Eingaben vornehmen, bei denen nur Zahlen und Buchstaben gültig sind, sollten Sie Zeichensätze auf nur die nützlichen beschränken, wenn Sie eine sichere Anwendung wünschen. Dies ist natürlich nicht möglich, wenn Sie eine Site im Stack Overflow-Stil ausführen, auf der Sie Codefragmente zulassen und solche, die einen großen Zeichensatz verwenden.

Denken Sie daran, dass für reflektiertes XSS ein Benutzer einer URL folgen oder zu dieser umgeleitet werden muss. Daher braucht es manchmal ein bisschen "Social Engineering" von einem Angreifer, um es auszunutzen. Normalerweise klassifiziere ich reflektiertes XSS als Sicherheitslücke mit mittlerem Risiko, es sei denn, es kann automatisch aus der Anwendung heraus ausgenutzt werden (z. B. eine automatische Umleitung irgendwo) oder die Anwendung selbst ist besonders empfindlich.

2
SilverlightFox

Ja:

  • Es ist immer eine schlechte Idee, bekannte Sicherheitslücken nicht zu beheben, aber auch ...
  • Die wichtigsten Browser, die versucht haben, reflektiertes XSS zu blockieren, erwägen, die Technologie einzustellen.

Ich verstehe, woher diese Frage kommt, aber die Technologie ist leider nicht perfekt und hält einen entschlossenen Angreifer fast nie auf:

In den letzten 3 Monaten haben wir alle internen XSS-Fehler untersucht, die den XSSAuditor ausgelöst haben, und konnten Bypässe für alle finden.

Das ist das Team von Chromium, das ankündigt, dass es Ratschläge gibt Chrome, um den XSSAuditor zu entfernen . Der angegebene Grund ist folgender:

Wir haben keine Beweise dafür gefunden, dass der XSSAuditor XSS stoppt, und stattdessen hatten wir Schwierigkeiten, Entwicklern in großem Maßstab zu erklären, warum sie die Fehler beheben sollten, selbst wenn der Browser angibt, dass der Angriff gestoppt wurde.

Entwickler fragen sich nicht nur, ob sie Korrekturen anwenden sollen, sondern auch, dass Sicherheitstester ihre Arbeit weniger gut erledigen. Da es ihnen schwer fällt, das Risiko zu rechtfertigen, ohne einen (manchmal zeitaufwändigen) Bypass zu finden:

Darüber hinaus haben wir Sicherheitspentester befragt und festgestellt, dass einige Schwachstellen nur dann melden, wenn sie eine Umgehung des XSSAuditor finden. Dies bedeutet, dass Verteidigungsteams sogar noch mehr behindert sind als Angreifer (als Verteidigungsteams, da Verteidigungsteams skalieren müssen) ihre Sanierungsbemühungen, während Angreifer nur etwas brauchen, das funktioniert).

Microsoft ist weniger offen über ihre Argumentation, aber auch kündigte letzten Juni an, dass sie den XSS-Filter einstellen werden :

Zurückgezogener XSS-Filter: Wir setzen den XSS-Filter in Microsoft Edge ab dem heutigen Build zurück. Unsere Kunden bleiben dank moderner Standards wie Content Security Policy geschützt, die leistungsfähigere, leistungsfähigere und sicherere Mechanismen zum Schutz vor Content-Injection-Angriffen bieten, mit hohe Kompatibilität mit modernen Browsern .

Ein weiterer guter Blog-Beitrag zum Thema ist dieser: https://portswigger.net/daily-swig/xss-protection-disappears-from-Microsoft-Edge
Beispielsweise wird auf Forschungsergebnisse verwiesen, die zeigen, dass der XSS-Filter in MSIE manchmal zu Sicherheitslücken führt, die sonst nicht ausgenutzt worden wären.

1
Luc

Ja, das ist immer noch relevant. Sie können versuchen, für Ihr Beispiel zu folgen:

http://localhost:8082/?query=<svg onload="alert('Hello!')"/>
0