Danke dedlfix !

[hkl]

Hallo dedlfix !

das ist ja wohl die tollste und praezieseste Antwort die ich mir auf meine Fragen erhoffen konnte !!

Vielen Dank dafuer !

Viele Grusse

Holger

echo $begrüßung;

Webseite B (wie böse) enthält einen Link mit schmutzigem Querystring, der auf Webseite A (wie artig) verweist. Dummerweise hat A aber eine XSS-Lücke
und ist außerdem beim Client als vertrauenswürdig deklariert. Somit könnte B veranlassen, dass der Code in A

Nicht andersherum ?
Wenn der Client beim Server A als vertrauenswuerdig bekannt ist  jetzt nicht wg. Bowser-Einstellungen sondern z.B. wg. der Firewall des Servers ?

Mein Szenario war aus Sicht des Clients betrachtet. Die Webseite A ist beim Client als vertrauenswürdige Seite deklariert. Der Server und Gegebenheiten auf ihm sind beim XSS nicht primär von Belang (er wird erstmal nur für das Einschleusen des Codes benötigt, der beim Client ausgeführt werden soll).

Dinge ausführt, die für B einen Nutzen haben könnten.
Auslesen von Cookie-Daten von A wäre ein Beispiel, darin könnten Anmeldedaten gespeichert sein.

Das hingegen versteh ich nicht im dem Kontext "Query-Strings ungeprueft zuruckschreiben":

Genau das ist die Lücke, denn durch das Nicht-Prüfen/Nicht-Behandeln der Eingabedaten gelangt ja erst der Code anstelle von eigentlich harmlosen Nur-Text in den Kontext des Browsers.

Ich betrachte an dieser Stelle nur den Browser. Und A und B sind die Quellen von denen der Browser seinen HTML- und Javascript-Code bekommt.

B macht ein response-redirect mit dem maliciuos code. Bon. A prueft nicht und schreibt den Code zum Client zurueck wo der ausgefuehrt wird und auf A irgendwas auloest ?
Das waere doch der gleiche Effekt als wuerde der malicious code direkt auf dem Client C ausgefuehrt.

Der Unterschied ist, dass die Webseite A als vertrauenswürdige Quelle eingetragen ist, B aber nicht, und der Code der lokalen Datei niemals ausgeführt wird, wenn der Nutzer sie nicht explizit aufruft. Im Web falsch geklickt ist hingegen schnell.

Und darin wuerde dann irgendwas auf der Site A passieren. Also macht sich A doch nicht da durch angreifbar, dass er den (JS-)String zuruecksendet, sondern dadurch dass er sich die Aktionen, die ueber das JS dann passieren, gefallen laesst.

Das Zurücksenden ist letzlich die Ursache für das Auslösen von weiteren Aktionen, die der Benutzer nicht gewollt hat. Das können ganz harmlose Dinge sein, wie das Senden einer Nachricht an einen anderen Benutzer des Systems. Der Empfänger denkt, dass er den Absender kennt und vertraut ihm und im Text steht irgendeine Schweinerei.

Aus aktuellem Anlass: https://forum.selfhtml.org/?t=141240&m=917626

echo "$verabschiedung $name";