it-swarm.com.de

Wie bringen Hacker das Opfer dazu, auf eine XSS-Angriffs-URL zuzugreifen?

Nach meinem Verständnis besteht die Grundidee von XSS darin, den Browser des Benutzers schädlichen Code ausführen zu lassen, der von den Hackern erstellt wurde.

Angenommen, eine Seite kann beim Zugriff auf diese URL ein beliebiges Skript laden:

http://www.example.com/apage?filename=malicious.js

Dann lädt der Browser das malicious.js Datei ohne Frage, und der Benutzer wird gehackt.

Meine Frage ist, wie Hacker den Benutzer auf eine solche URL zugreifen lassen?

Wie im obigen Fall und bei allen anderen ähnlichen Techniken haben alle eine Voraussetzung: Der Benutzer muss Maßnahmen ergreifen, die er normalerweise nicht ergreifen würde.

Wenn der Hacker kommen muss, um zu sagen "Hallo, da ist etwas Lustiges, schau mal!" Für alle ist das kein sehr effektiver Angriff.

Gibt es also Tricks, um dies automatisch zu erreichen? Oder irgendwelche realen Fälle, die dies verursachen?

32
Hetfield Joe

der Benutzer hat einige Aktionen ausgeführt, die er nicht wie gewohnt ausführt

Das Klicken auf einen Link scheint für die meisten Benutzer eine übliche Aktion zu sein.

Siehe zum Beispiel diese Studie , in der 56% der Benutzer auf Links in E-Mails eines unbekannten Absenders und ~ 40% auf Links geklickt haben, die über Facebook gesendet wurden (obwohl 78% sich der Möglichkeit bewusst waren Achtung). 50% gaben an, nicht auf den Link geklickt zu haben, weil sie den Absender nicht kannten.

Das ist schon eine beeindruckende Erfolgsquote. Wenn das Opfer den Angreifer kennt oder wenn der Angreifer die Identität einer Person fälscht, die er kennt, kann diese Rate noch weiter erhöht werden.

In sozialen Netzwerken kann reflektiertes XSS auch wurmbar sein. Zusätzlich zu der böswilligen Aktion könnte das injizierte Skript Nachrichten mit dem Link an alle Freunde des Opfers senden (so etwas ist beispielsweise Twitter passiert).

Neben E-Mail können Links auch in Foren, Blogs, Issue-Trackern usw. verteilt werden. Dies geschah zum Beispiel mit Apache .

28
tim

Das habe ich mich auch immer gefragt, und als ich gefragt wurde, wurde mir normalerweise gesagt, dass "Benutzer nicht aufpassen und auf alles klicken". Auf diese Weise klingt es so, als wäre reflektiertes XSS nicht wirklich eine Sicherheitslücke von Software, sondern eine Sicherheitslücke von Benutzern. All dies klang für mich seltsam, weil ich die Art von Person bin, die normalerweise die Linkvorschau überprüft (mit der Maus über den Link im Browser schwebt) und wenn mir jemand sagt, ich soll auf klicken Diese Frage auf StackExchange und ich sehe das seltsame Format (siehe Pfad), ich werde nicht klicken.

Ich muss jedoch sagen, dass es Möglichkeiten gibt, reflektiertes XSS gefährlicher zu machen, als es zunächst scheint. Beachten Sie die folgenden Punkte:

  • Automatische Klicks, Weiterleitungen oder ähnliche Tricks: Sie müssen nicht klicken, sondern müssen nur auf einer schädlichen Website landen, die automatisch zur Zielwebsite umleitet und das schädliche Javascript ausführt. Wenn Sie auf der Zielwebsite angemeldet sind, veranlasst der Angreifer Sie, willkürliches Javascript auszuführen und böswillige Aktionen auszuführen (Senden oder Löschen von Inhalten usw.).
  • Websites, die normalerweise lange oder komplexe URLs haben (nicht benutzerfreundlich) und denen der Benutzer ohnehin eher vertraut. Ich neige dazu, dies bei Amazon zu sehen, die Links sind sowieso nicht lesbar.
  • Browser, mit denen Sie eine Vorschau nicht einfach sehen können, wie in mobilen Browsern oder anderer Software, in der es nicht so einfach ist, nur zu schweben. Ich muss zugeben, dass ich mir nicht die Zeit nehme, Links auf Mobilgeräten zu überprüfen. Ich tippe einfach auf, obwohl ich auf Mobilgeräten nur versuche, eine eingeschränkte Auswahl vertrauenswürdiger Websites zu verwenden.
  • Der Angreifer kennt das Opfer, weiß, wie er sie davon überzeugen kann, auf einen Link zu klicken oder eine Seite zu besuchen, und das Opfer kann in einigen Fällen sogar dem Angreifer vertrauen. Eine zufällige E-Mail von einem völlig Fremden ist nicht dasselbe wie eine private Facebook-Nachricht von einem (böswilligen) Bekannten.
  • Boobs and Lols: Bilder mit Boobs, Lolcats usw. können dazu führen, dass Sie vorübergehend das Bewusstsein verlieren, und Sie haben möglicherweise das Gefühl, dass Sie sofort darauf klicken müssen, als wäre es ein Gesetz der Physik.

Wie Sie sehen können, können die mit reflektiertem XSS verbundenen Risiken sehr unterschiedlich sein, abhängig vom Benutzer, dem Vertrauen in die betroffene Website, den möglichen Aktionen auf der Zielwebsite usw. Trotzdem bleibt es auf jeden Fall eine Software-Schwachstelle. weil es per Definition eine willkürliche Ausführung von Javascript ermöglicht, indem eine Schwäche bei der Bereinigung von Eingaben ausgenutzt wird.

7
reed

Das Beispiel, das Sie gegeben haben, ist sehr trivial. Es gibt viele Anwendungen mit Dutzenden von GET-Parametern in der gemeinsam genutzten URL. Alles, was der Angreifer benötigt, ist, dass einer von diesen für reflektiertes XSS anfällig ist, damit dies erfolgreich ist. Wenn der Link, den jemand erwartet, lang und komplex ist und das, was er erhält, lang und komplex ist, untersucht er möglicherweise nicht jeden Parameter.

Sie könnten auch einen URL-Shortener verwenden.

6
Richard

Es gibt zwei Haupttypen von XSS: Reflective und Persistent. Permanentes XSS ist, wenn es auf dem Server gespeichert ist und andere Benutzer betrifft, während Reflective nicht gespeichert wird, aber dennoch andere Benutzer betreffen kann.

Eine Methode, die ich gesehen habe, besteht darin, etwas wie eine Weiterleitung in einem Kommentar zu speichern, der eine schlechte Desinfektion aufweist. Auf diese Weise wird der Code serverseitig gespeichert, und wenn jemand die Seite anfordert, wird der Code zusammen mit den Kommentaren geladen, wodurch der Codeblock ausgelöst wird. Dies kann dann das Opfer auf die Website des Angreifers umleiten, auf der andere böswillige Dinge auftreten können, z. Gefälschte Anmeldeseiten für Erntemaschinen mit Anmeldeinformationen, Anzeigenstapel usw.

Wenn Sie weitere Informationen benötigen, lassen Sie es mich wissen. Ich kann sie bearbeiten, wenn ich wieder am PC bin, und weitere Details hinzufügen.

BEARBEITEN: Wenn beispielsweise eine Site für diese Art von Angriff anfällig war, könnte ein Kommentar hinterlassen werden, der alle Benutzer, die diese Seite besucht haben, auf eine neue Site umleitet. Diese neue Site könnte eine nahezu identische Kopie der ursprünglichen Site sein, für die entwickelt wurde Lassen Sie sich erneut anmelden und stehlen Sie dann Ihre Anmeldeinformationen. Da Benutzer auf mehreren Websites in der Regel dieselben Kennwörter verwenden, können diese Anmeldeinformationen verwendet werden, um sich an anderer Stelle anzumelden usw.

Grundsätzlich

3
Connor J

Jedes Mal, wenn ein Webentwickler dies tut:

<script src="someOtherDomainThanThisOne"></script>

Das ist ein möglicher Weg für XSS. Die Site, die der Benutzer besucht, muss nicht im geringsten kompromittiert werden, sondern nur die Site, auf der sich das Skript befindet.

Zum Beispiel, wenn ich ein Webentwickler bin, der an meiner Website widgets.com arbeitet und diese auffällige neue js-Bibliothek finde. Anstatt es direkt von meiner Website aus zu hosten, habe ich den unsicheren Pfad gewählt, es (über das Skript src) von cooljslibs.com aufzunehmen. Irgendwann in der Zukunft wird cooljslibs.com entweder als Schurke eingestuft, oder jemand hackt es und kompromittiert die gehosteten Dateien. Nun wurde widgets.com in keiner Weise gehackt, aber da es blind Code von cooljslibs.com ausführt, hat es seine Benutzer und seine Website gefährdet.

Dies kann teilweise durch die Verwendung der Subressourcenintegrität verringert werden, die im Grunde genommen eine Hash-Überprüfung der Datei eines Drittanbieters erzwingt. Es ist immer noch am besten, es zusätzlich selbst zu hosten. Sie können mehr darüber erfahren hier . Ex:)

<script src="https://example.com/example-framework.js"
    integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
    crossorigin="anonymous"></script>
0
user101448

Ich denke, ein großartiges Beispiel dafür, wie ein XSS in freier Wildbahn eingesetzt werden kann, ist die jüngste Datenverletzung von British Airways. Wie in diesem Artikel erläutert: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ Die Angreifer haben ein bösartiges Javascript gespeichert und ein übliches Skript auf der Zahlungsseite ersetzt , das würde die vom Benutzer eingegebene Kreditkarte stehlen. Obwohl dies kein typischer XSS-Angriff ist, da sie Zugriff auf den Server hatten, um das Skript zu ändern, ist dies immer noch eine sehr gültige Demonstration eines solchen Angriffs.

Wenn Sie auf irgendeine Weise gültiges Javascript auf einer Website speichern können (gespeichertes XSS), können Sie das Cookie des Benutzers stehlen und sich als dieser Benutzer ausgeben und auf dieselben Informationen (wie Profildaten) zugreifen.

In Bezug auf reflektiertes XSS müssen Sie Social Engineering durchführen und den Benutzer dazu bringen, auf einen schädlichen Link zu klicken, wie andere darauf hingewiesen haben.

Bei einigen Angriffen muss das Opfer die Seite des Angreifers besuchen. Es gibt verschiedene Möglichkeiten, dies zu tun:

  • Phishing. Senden Sie dem Opfer eine E-Mail, eine Facebook-Seite und eine LinkedIn-Einladung mit einem Link, der vorgibt, etwas anderes zu sein. Die Erfolgsquote hängt davon ab, wie viel Aufwand in die Kampagne investiert wird. Erfolgsquoten über 50% sind jedoch keine Seltenheit. Insbesondere, weil der Domainname übereinstimmt: Sie versuchen, Benutzer von somegoodsite.com dazu zu bringen, auf einen somegoodsite.com-Link zu klicken, und dies kann im Allgemeinen als vertrauenswürdig eingestuft werden.
  • Aufnahme aus der Site selbst. Manchmal erlaubt die Site das Hinzufügen von Benutzerinhalten. Wenn der Angreifer seiner Profilseite einen Iframe hinzufügen kann, wird jeder angegriffen, der auf sein Profil zugreift. Es ist jedoch ziemlich ungewöhnlich, einer Site einen Iframe hinzufügen zu können.
  • Man-in-the-Middle-Angriff. Bei einem Man-in-the-Middle-Angriff kann der Angreifer unverschlüsselte Daten ändern. Selbst wenn somegoodsite.com HTTPS verwendet, kann der Angreifer einen Iframe in eine Webseite einfügen, die kein HTTPS verwendet, und Ihren Browser veranlassen, die URL zu besuchen.
  • Anzeige. Auf einigen Websites werden aufdringliche Anzeigen geschaltet, die eine Seite in einen Iframe oder sogar ein neues Fenster laden. Ich erhalte diese manchmal mit der Meldung, dass ich ein kostenloses iPhone gewonnen habe, aber Sie können sie auch mit einer XSS-Nutzlast ausführen. Ich denke jedoch, dass Websites, auf denen Werbung aufdringlich ist, ziemlich selten sind.
0
Sjoerd