Home Technische Artikel Angriffe auf Cross-Site Scripting (XSS) im 4. Quartal 2020: Trends und Best Practices
Applications

Angriffe auf Cross-Site Scripting (XSS) im 4. Quartal 2020: Trends und Best Practices

About The Author

Outline

Ursprüngliche Quelle: Edgecast

Die Sicherheit von Webanwendungen ist nach wie vor eine der wichtigsten Bedrohungen für große und kleine Unternehmen. Laut dem Verizon 2020 Data Breach Investigations Report (DBIR) betrafen 43 % aller Datenschutzverletzungen eine Webanwendung,¹ und 80 % aller Hacking-Vektoren zielen auf Webanwendungen ab.²

Im vierten Quartal 2020 verzeichnete Verizon Media im Vergleich zu den Vorquartalen einen deutlichen Anstieg des Cross-Site-Scripting (XSS)-Datenverkehrs in unserem Content Delivery Network (CDN). In diesem Blog werden einige Datenverkehrspunkte untersucht und eine der am häufigsten versuchten XSS-Payloads analysiert. Wir teilen auch mit, wie diese Daten zur Anwendung von Schutzmaßnahmen verwendet werden können.

Verwenden Sie diese Inhalte als handlungsorientierte Anleitung zum Umgang mit potenziell schädlichem XSS-Datenverkehr, der an die Haustür Ihres Unternehmens klopft. Es kann Ihnen auch dabei helfen, ein notwendiges Sicherheitsgespräch mit Ihrem Führungsteam und Ihren Geschäftspartnern/Kollegen im Betrieb zu führen.

‍We Haben Sie die Daten – lassen Sie uns sie untersuchen

‍The Verizon Media WAF hat im vierten Quartal 2020 1,5 Milliarden Anfragen abgemildert. Wir definieren „Mitigate“ als jedes WAF-Ereignis, das einen Block, eine benutzerdefinierte Antwort oder eine URL-Umleitung ausgelöst hat. Diese 1,5 Milliarden Blöcke stellen HTTP-Anforderungen dar, die andernfalls die Ursprungsserver unserer Kunden erreicht hätten. Diese Daten sagen uns:

  1. Die Menge an Hintergrunduntersuchungen ist immens. Sie irren sich, wenn Sie glauben, dass Sie sicher sind, weil Ihr Ziel es nicht Wert ist, anzugreifen oder weil Sie nicht bekannt sind. Laut Verizon DBIR „wenn Sie uns eine gemischte Metapher erlauben, gibt es in diesem Fall keine Übertreibung des Bären, da die Bären alle in großen Mengen 3D-gedruckt und automatisiert werden, um Sie zu jagen.“³
  2. Wenn Ihre Webanwendungen geschützt sind, kann ein solches Scannen nicht schädlicher erscheinen als ein Einbrecher, der Türknauf rudelt, und es ist harmlos, dass derartiger Datenverkehr Ihre Server erreicht, abgesehen von einer zusätzlichen Belastung Ihres Servers. Doch im asymmetrischen Krieg gegen die Cybersicherheit muss der Angreifer nur einmal Recht haben, was es ihnen leichter macht, in Zukunft Recht zu haben. Warum lässt der Einbrecher den Türknauf ruckeln, wenn du es verhindern kannst?

Um dieses Haus noch weiter zu fahren, wollen wir uns einige der blockierten Datenströme aus dem 4. Quartal 2020 genauer ansehen.

Der blockierte XSS-Datenverkehr (Cross-Site Scripting) hat sich in den letzten drei Quartalen von der obersten Stelle im 2. Quartal 2020 auf die vierte Stelle im 4. Quartal 2020 verschoben. In diesem Zeitraum hat sich das Volumen fast verdoppelt, was 10 % des blockierten Datenverkehrs entspricht.

Abbildung 1. In nur sechs Monaten konnten wir den XSS-Datenverkehr mehr als verdoppeln.

‍Getting um Ihren XSS-Traffic zu erfahren

‍According für das Open Web Application Security Project (OWASP) treten XSS-Fehler auf, wenn eine Anwendung nicht vertrauenswürdige Daten in einer neuen Webseite enthält, ohne dass eine ordnungsgemäße Validierung oder ein Escaping erfolgt, oder wenn eine Anwendung eine vorhandene Webseite mit benutzerdefinierten Daten aktualisiert, die eine Browser-API verwendet, die HTML oder JavaScript erstellen kann. Mit XSS können Angreifer Skripte im Browser des Opfers ausführen, die Benutzersitzungen entführen, Websites verfälschen oder den Benutzer auf schädliche Websites umleiten können.

Diese Gefährdung gefährdet Ihre Infrastruktur, die Vertraulichkeit und Integrität Ihrer Daten sowie die Verfügbarkeit von Daten, die über das Internet bereitgestellt werden. Diese Angriffe können zu unbefugtem Zugriff auf Inhalte, zum Verlust persönlich identifizierbarer Informationen (PII) und zur Verbreitung privater/urheberrechtlich geschützter Informationen führen.

Dies ist ein Problem, da nichts verborgen ist, sobald es mit dem Internet verbunden und zugänglich ist: Wenn Sie es aufstellen, wird es gescannt. Sobald eine neue Webanwendung online geht und dem Internet ausgesetzt wird, wird sie getestet, um zu sehen, wie sie auf verschiedene Aktionen oder Anfragen reagiert. Die Ergebnisse dieser Ergebnisse können eine interessante Drehung der Handlung erzeugen, die wir in Kürze besprechen werden.

Lassen Sie uns zunächst den Umfang der potenziellen Gefährdung weiter untersuchen. Viele Websites, Webanwendungen und Server empfangen und verarbeiten Anfragen außerhalb des geschützten internen Netzwerks eines Unternehmens. Infolgedessen sind sie anfällig für verschiedene schädliche Bedrohungen, die von OWASP gruppiert werden, einschließlich SQL-Injections, XSS und Distributed Denial-of-Service (DDoS)-Angriffe auf Anwendungsebene.

Angesichts der Zunahme von XSS-Angriffen, die von Verizon WAF erkannt wurden, ist es keine Überraschung, dass XSS auch 2020 die Liste der MITRE CWE Top 25 anführt:⁴

Abbildung 2. Eine kurze Auflistung der Schwächen in den Top 25 der CWE 2020, einschließlich der Gesamtpunktzahl der beiden.

So wie wir eine Zunahme des blockierten XSS-Datenverkehrs beobachten konnten, ist auch die Anzahl der tatsächlichen Schwachstellen, die in der National Vulnerability Database (NVD) dokumentiert sind und auch mit XSS-Exploits verbunden sind:

  • ‍513 in den letzten drei Monaten dokumentierte XSS-Schwachstellen (171 pro Monat)
  • ‍5,507 in den letzten drei Jahren dokumentierte XSS-Schwachstellen (153 pro Monat)
  • ‍16,936 ständig dokumentierte XSS-Schwachstellen

Ja, Verteidiger verwenden dieselben Tools wie Angreifer, um Schwachstellen zu ermitteln. Daher ist es wichtig, das Potenzial zu erkennen, dass die Existenz von böswilligem Traffic nicht zwangsläufig bedeutet, dass hinter dem Traffic eine böse Absicht steckt. Aber es könnte sein.

Wenn ein neugieriger schlechter Schauspieler ein System erfolgreich scannt, könnte er zumindest einen XSS-Exploit versuchen – alles im Geiste der Aufklärung. Schlimmer noch: Die Rekonstruktionsaktivität – und die daraus gewonnenen Ergebnisse – könnte dazu verwendet werden, eine kompromittierende oder zerstörerische Nutzlast über XSS zu löschen oder als Sprungbrett für etwas schändlicheres, wie z. B. eine serverseitige Anforderungsfälschung (SSRF), zu dienen.

‍Is ist das ein „ausgezeichneter Trittstein“, wie ich sehe?

‍Remember das Türknauf-wackelnde Szenario, das wir vorhin erwähnt haben? Es ist Zeit, diese Metapher zurückzubringen.

Die meisten XSS-Datenverkehr und -Ereignisse sind für sich selbst vielleicht nicht kritisch, aber sie könnten zu erheblichen Herausforderungen und Problemen führen – ein Schritt zu einem erfolgreichen Kompromiss, wenn Sie so wollen.

Erfolgreiche XSS-Angriffe können Angreifern ermöglichen, beliebige HTML- und JavaScript-Dateien im Browser eines Opfers auszuführen. In der Regel muss der Benutzer mit einem bösartigen Link interagieren, der auf eine vom Angreifer kontrollierte Seite verweist, wie z. B. Websites oder Werbung für Wasserlöcher.

Betrachten wir nun die oberste Regelverletzung für das 4. Quartal 2020 – intern als Regel-ID 941100 bezeichnet –, die einer der obersten Payloads zugeordnet ist und die Fähigkeit demonstriert, XSS als Stepping-Stone-Angriff zu verwenden:

„><Script >Alert(String.fromCharCode(88,83,83))</script>“

Dies ist eine sehr häufige XSS-Testzeichenfolge in vielen Code-Repositorys, wie z. B. htmlpurifier.org.⁵. Während der Suche nach der Überprüfung, ob diese bestimmte Payload funktioniert, wird ein Popup-Warnungsfeld mit der Zeichenfolge „XSS“ angezeigt, das dem Angreifer sofort bestätigt, dass eine bestimmte Website für reflektierte XSS anfällig ist.

Sobald ein Angreifer verifiziert hat, dass ein reflektiertes XSS vorhanden ist, werden die reflektierten Angriffe über eine andere Route zugestellt, z. B. in einer E-Mail-Nachricht oder einer anderen Website. Wenn ein Benutzer dazu verleitet wird, auf einen schädlichen Link zu klicken, ein speziell gestaltetes Formular zu senden oder einfach nur eine schädliche Website zu durchsuchen, wird der eingespritzte Code zur anfälligen Website weitergeleitet, wodurch der Angriff zurück zum Browser des Benutzers gesendet wird.“⁶

Abbildung 3. Wie Cyberangreifer XSS-Schwachstellen nutzen

Dieser Angriff kann alles auf der Website ausführen, was der angegriffene Benutzer ausführen kann, einschließlich der „Offenlegung des Sitzungs-Cookies des Benutzers, sodass ein Angreifer die Sitzung des Benutzers entführen und das Konto übernehmen kann.“⁷ ein Skript, das das Kennwort eines Benutzers ändert, das im Namen des Benutzers übermittelt wird, kann beispielsweise zu einer Kontoübernahme führen.

Es gibt noch weitere Beispiele für einen Sprungstein, auf die man zurückgreifen kann. In einem anderen öffentlich dokumentierten Fall wurde ein SSRF-Angriff ursprünglich über einen XSS-Exploit gestartet, und der Sicherheitsforscher „konnte von XSS innerhalb eines Images bis hin zu beliebigen lokalen Dateien auf dem Server eskalieren“⁸

Nicht jeder Forscher (und auch nicht jeder Cyberkriminelle) wird Geduld haben, seinen XSS-Exploit mit etwas sinnvollerem zu verknüpfen. Ein XSS für größere und bessere Dinge zu halten scheint jedoch eine gängige Methode für einige Forscher zu sein, die den großen Preis in ihren Bug-Bounty-Programmen erzielen wollen.

‍Mitigation und defense‍

Ohne Daten ist es schwierig, eine Entscheidung zu treffen. Es wird jedoch einfacher, einen Weg zu identifizieren, der Sie zum gewünschten Ergebnis führt, sobald Sie einen Einblick in eine Situation haben. Hier finden Sie eine Sammlung von Tipps und Ressourcen, die Ihnen helfen, das Risiko von XSS-Datenverkehr für Ihr Netzwerk und Ihr Unternehmen zu minimieren.

  1. Stellen Sie sicher, dass Sie alle internetbasierten Geräte kennen und dass sowohl Legacy- als auch Testsysteme entweder für die Absicherung in Betracht gezogen oder offline geschaltet werden. Dies ist besonders wichtig im Zeitalter der Cloud-Infrastruktur, in dem Entwicklungsteams mit nur wenigen Klicks oder durch Einreichen eines Formulars Maschinen in Betrieb nehmen können.
  2. Webserver ordnungsgemäß konfigurieren und sichern. Nutzen Sie Tools wie Center for Internet Securities Benchmarks, um zu verstehen, wie Sie die Steuerelemente Ihres Servers konfigurieren. Konfigurieren Sie Ihre TLS-Konfigurationen ordnungsgemäß, um sich vor MITM-Angriffen zu schützen.
  3. Regelmäßig Patches für alle internetbasierten Server. Manchmal sind häufig verwendete Frameworks anfällig für XSS. Im Februar 2021 listet die ATT&CK-Datenbank VON MITRE fast 17.000 Schwachstellen und Schwachstellen mit einer Verbindung zu XSS auf.
  4. Überprüfen Sie regelmäßig die Effektivität Ihrer Sicherheitsabsicherung. Verwenden Sie die gleichen DAST-Tools (Dynamic Application Security Testing), die die Angreifer verwenden, wie OWASP ZAP oder ähnliche Tools zum Scannen von Schwachstellen in Kali Linux. Alternativ können Sie einen DAST- oder Penetrationstestdienst verwenden, um anfällige Internet-Server zu ermitteln und zu scannen.
  5. Aktivieren Sie eine Web Application Firewall (WAF), um häufige Angriffe zu blockieren.
  6. Halten Sie die WAF auf dem neuesten Stand, um erkannte Schwachstellen sofort zu blockieren, sodass das Anwendungsteam eine Problembehebung bereitstellen kann. Aktualisieren Sie die WAF, sobald neue Regeln verfügbar sind, um sich vor neu entdeckten Sicherheitsanfälligkeiten zu schützen.
  7. Aktivieren Sie die Protokollierung, und prüfen Sie diese Protokolle.
  8. Schützen Sie Ihre Websites und kritische Netzwerkinfrastruktur vor volumetrischen Angriffen mit einem hochredundanten autoritativen DNS-Service und hochgradig verteilten DDoS-Schutz- und Webbeschleunigungsdiensten, d. h. dem CDN. ‍

Beginne mit deinem data‍

Möglicherweise haben Sie Ihre Apps genau auf die Bereitstellung von Inhalten und eine robuste Reihe von Sicherheitskontrollen abgestimmt, um Risiken zu mindern und möglicherweise sogar Angriffe zu blockieren, die diese Inhalte enthalten. Warum lassen Sie jedoch potenziell schädlichen Datenverkehr überhaupt erst in Ihr Netzwerk eindringen? Warum das Risiko eingehen, dass eine Richtlinie verpasst oder eine Kontrolle umgangen wird?

Kunden von Verizon Media Security verfügen über zwei Funktionen, die sie vor Bedrohungen schützen können:

  1. Wir sehen potenziell schädlichen (oder zumindest wenig hilfreichen) Netzwerkverkehr, der auf Ihre Website trifft.
  2. Die integrierte Verizon Media WAF kann aktiviert werden, um schädlichen Datenverkehr zu blockieren, bevor er automatisch zu einem Problem wird.

Machen Sie einen wichtigen Schritt zur Verbesserung der Sicherheit Ihrer Webanwendungen. Kontaktieren Sie uns noch heute, um mehr zu erfahren.

Referenzen

  1. Verizon, „2020 Data Breach Investigations Report, Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Seite 7.
  2. EBD, Seite 88.
  3. EBD, Seite 23.
  4. CWE, „2020 CWE Top 25 Most Dangerous Software Sschwäches“, CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
  5. HTMLPurifier, „HTML Purifier XSS Attacks Smoketest“, HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
  6. OWASP, „Cross Site Scripting (XSS)“, owasp.org, owasp.org/www-community/attacks/xss/
  7. Ebd
  8. Buerhaus, Brett, “Eskalating XSS in PhantomJS Image Rendering to SSRF/local-file read, buer.haus. 29. Juni 2020.