Cross Site Scripting Beispiel / Erklärung + XSS Tutorial

Hast Du schon einmal überlegt, dass Dich jemand über Chats angreifen kann?

Nein? Dann schau Dir diese Tutorial an, um mehr über fieses Remote-Hacking zu erfahren.

Ich zeige Dir, was Cross-Site-Scripting ist und wie Du Dich sicherst.

Um was geht’s? – Cross Site Scripting

Bei Cross-Site-Scripting senden Angreifer A an das Opfer O via Chat den Inhalt einer Script Datei. Falls der Chat ganz ungeschützt ist, erhält der Empfänger O nicht den Code-Snippet, sondern muss die Auswirkungen der Script Datei von A ertragen.

Wenn Angreifer A in ein Forum seinen Schadcode einstellt, der nicht geschützt ist, dann führt sich der Schadcode bei jedem Benutzer des Forums aus. Außerdem kann A:

• Browser-Sessions erstellen
• Deinen Webbrowser beginnen zu kontrollieren
• negative Inhalte einstellen

Knappe Einordnung

„Cross-Site-Scripting“ (XSS) ist  webseitenübergreifenden Skripting wie z. B. Refleted XSS, DOM-Based.  Diese Art von Hacking  kann man in die HTML Injection einordnen. Oft finden die Angriffe mit der Nutzung von JavaScript statt.

Mit JavaScript können Hacker über den Browser Kamera, Mikrofone, Dateisystem und Standort-Sensor ansteuern. Die HTML5 API ermöglicht diesen Zugriff mit JavaScript.

Weitere Arten sind Cross-Site Request Forgery und Cross-Site Authentication

DAS. Sagen die Medien.

Oft wird XSS genutzt, um Backlinks zu verteilen. Ungeschützte Kommentarfelder und Formular missbraucht das Script, um diese zu füllen und abzusenden. Der generierte Backlink hilft den Angreifer dabei seine Webseiten in Google höherer ranken zu lassen.

Diese Technik der Backlink-Setzung ist nach Google nicht korrekt und führt, wenn es gefunden wird zum Abranking. Somit ist XSS eine Black-Hat-Methode, um Backlinks zu setzen.

IT einfach erklärt

XSS gibt es in drei verschiedenen Arten, wie es Hacker heutzutage nutzen: reflektierendes, persistentes und lokales

• Bei dem reflektierenden XSS sendet der Angreifer eine Mail zu den Opfern und der Klick auf den Link startet den Schadcode. (Client-seitig) Mit Formularen versuchen die Angreifer die Opfer davon zu überzeugen, diese auszufüllen und zuzulassen, dass die Schadwebseite eine Cookie setzen kann.
• Persistente XSS sind server-seitig. Die Script speichern sich in den Webcaches und SQL-Datenbanken ein und können verteilt werden.
• Lokales / DOM-basiert: Für diese Methode braucht der Hacker keinen Einfügungen auf einer Webseite zu machen. Über einen gefälschten GET-Parameter in die URL fügt der Hacker JavaScript ein. Wenn man noch die URL kürzen lässt, erkennt der Nutzer nicht, dass es sich um einen sehr langen Link mit eingefügten JavaScript Code handelt.

Blick in den Code

XSS kann der Angreifer nicht nur in <script> Tags packen, sondern auch in body, input, link, umg, table, div und obejct Tag. Die Tags rufen Resourcen auf, die JavaScript enthalten.

Mit dem Aufruf der Webseite laden die DOM-Objekete mit den verlinkten Ressourcen:

ATTACKE! – XSS auf Webseiten

Der Hacker kann beispielsweise in ein Kommentarfeld eines Blogs eine Script Datei einfügen, die in der SQL-Tabelle der Webseite abgespeichert wird. Die erstellen Kommentare zeigt die Webseite unterhalb des Posts kompiliert an.

Im Browser des Seitenbesuchers führt sich das Schad-JavaScript aus und kann aktiv werden.

Und WordPress ist aber schon schlauer:

Sicherungsmaßnahme

Wenn der Browser-Nutzer sich gegen XSS schützen möchte, müsste er JavaScript und alle Flash-Sprachen standardmäßig deaktiviert zu haben. Diese Strategie schützt 100% vor XSS angriffen.

Aber:

Im Web 3.0 sind Cookies, Sessions und Logs eine Selbstverständlichkeit. Die Nutzer müsste bei Deaktivierung von JavaScript auf vieles Verzichten: Weder in Amazon kann der vorsichtige Nutzer etwas kaufen, noch kann er auf Netflix eine Serie schauen. Viele Webseiten können gar nicht mehr ohne JavaScript dargestellt werden.

Web Apps und PWAs basieren zum großen Teil auf JavaScript. Diese Sprache ist eine der beliebtesten überhaupt im Web, da viele Entwickler diese Script Sprache beherrschen.

Das No-Script Plugin zwingt Firefox allen JavaScript-Codes zu ignorieren und nicht auszuführen.

Bei XSS Attacken sind aber nicht die Nutzer in der Pflicht, sondern die Webseiten-Hoster. Sie müssen dafür Sorge tragen, dass die Hacker nicht so einfach in ihren Kommentar-Felder JavaScript einbetten können. Außerdem sollte die Hoster Googles reCAPTCHA Codes nutzen, sodass ein Web-Bot nicht alle Strategien testen kann, mit der der Bot JavaScript auf die Webseite stellen kann.

Extra-Sicherheit: Bollwerk gegen XSS

Um XSS zu erkennen, sollte der Hoster alle PHP-Scripte zum Kommentare oder Formulare einzufügen überprüfen:

• Ist der Text zu lange?
• Kommen Sonderzeichen zum Einsatz?
• Ist im Kommentar HTML oder JavaScript Tags erkennbar?
• Werden URLs aufgerufen?

PHP stellt einige Funktionen zu Verfügung, die vermeiden, dass schädlicher Code in Deine Datenbanken gerät. Mit PHP kannst Du einfach mit strip_tags() alle Tag löschen. Alle HTML-Sonderzeichen wandelt die PHP-Funktion htmlentities() um in UTF-8 Texte, der als sichtbaren Code im Browser erscheint.

Außerdem kannst Du nutzen:

• Black- / Whitelisting
• Bei WordPress alle Kommentare moderieren.

Credits

Icons made by Gregor Cresnar from www.flaticon.com is licensed by CC 3.0 BY – Icons made by dDara from www.flaticon.com is licensed by CC 3.0 BY – Icons made by Icomoon from www.flaticon.com is licensed by CC 3.0 BY –Icons made by Those Icons from www.flaticon.com is licensed by CC 3.0 BY – Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY – Icons made by srip from www.flaticon.com is licensed by CC 3.0 BY