beim Durchsehen fällt mir auf: sollte der Name Leerzeichen enthalten, also zB Otto Normalverbraucher, gibts ein Problem, das aber durch 2 kleine Code-Änderungen umgangen werden kann.

var wen = ausloeser.firstChild.data;
wird zu

var wen = escape(ausloeser.firstChild.data);

(wandelt Otto Normalverbraucher zu Otto%20Normalverbraucher)

und

var wer = location.search.substr(1);
zu

var wer = unescape(location.search.substr(1));

(zurück zu Otto Normalverbraucher)

grundsätzlich find ich es sowieso sauberer mit der member id zu arbeiten. bei nicknamen kommen zu den sonderzeichenproblemen im http-protokoll ja dann auch noch html-codeinjectionprobleme dazu (member mit namen, wie "<script>history.back()</script>" und so ;-)).

habe grade im firefox getestet:
name des members: "<img src='1.jpg'>"
ausgegeben mit der php-funktion htmlentities():

<span onclick="popup(this)">&lt;img src='1.jpg'&gt;</span>

also noch alles im grünen bereich!
aber dann im popup mit:

document.write(unescape(location.search.substr(1)));

wird das bild angezeigt!

@detleff:
kann ich nicht nachvollziehen,

unescape(escape("<")) 

ergibt bei mir &lt; und nicht <

Übrigens: wenn du document.write (und sein hässliches Brüderlein innerHTML) nicht verwendest, also so wie in Antwort 21 sauber arbeitest, bist du beim JavaScript auf der sicheren Seite.
Aber auch wenn da jemand mit viel Mühe Schadcode einschleust: es wird doch nur auf seiner eigenen Kiste ausgeführt!

Dass du serverseitig die Formulareingaben immer auf eingeschleusten Code überprüfen musst kann dir sowieso kein JavaScript abnehmen.

hab grad ein wenig gebastelt und habe gedacht das problem lokalisiert zu haben, aber die gegenprobe ist gescheitert. jetz bin ich wieder so weit wie am anfang. ;-)
aber egal. wollte trotzdem schon mal vorweg zu deinen aussagen stellung nehmen:

der code wird auf der kiste desjenigen ausgeführt, der dem einschleuser eine mail schicken möchte!

ganz andere baustelle: hier geht es darum, dass eine serverseitig getroffene sicherheitsmassnahme nachträglich von js sabotiert wird.

generell wollte ich ja nur darauf hinaus, dass man den umgang mit "fremdcode" weitestgehend vermeiden sollte und wenn möglich durch selbst erzeugten (member id) ersetzen. vor allem sollte man vermeiden, ihn durch eine "blackbox" wie js zu "jagen". und das ist unabhängig von der frage, ob das js gut oder schlecht programmiert ist.

E-Mail? Bahnhof?

bislang dreht es sich um:

eine Seite mit einem Namen in einem span-Element

darauf ein onclick-Event

ein JavaScript-PopUp

darin wird ein Parameter beim PopUp-Aufruf per JavaScript verarbeitet

-> das ist alles userseitig.

@rfb:
ok. also nochmal alles ganz ausführlich:

üsch gibt eine liste von membern aus, die er aus einer mysql-datenbank liest. wenn man einen dieser namen anklickt, öffnet sich ein kontaktformular (siehe antwort 2) und man kann eine (art?) mail an jenen schicken.

nun hattest du ja eine lösung vorgeschlagen, wie man den namen des empfängers an das popup übermitteln kann, ohne dieses serverseitig dynamisch zu erzeugen, indem man mit js ein query an die popupurl hängt und dieses im popupdokument wieder mit js einliest. so weit so gut.

dann viel dir ein, dass es ein problem geben könnte, wenn der membername ein leerzeichen enthält und du hast das skript dafür modifiziert.

das grundlegende prinzip dieses problems ist es ja, dass man mit daten arbeitet, die man zum zeitpunkt der programmierung noch nicht kennt, da sie von den usern erzeugt werden.
das hat mich auf einen anderen gedanken gebracht, nämlich das artverwandte problem von userseitiger codeinjection.

vorweg:
natürlich muss man versuchen, massnahmen zu setzen, die es dem user von vorneherein verunmöglichen, code zu injezieren. aber das problem ist natürlich komplex (wie man auch hier im sn beobachten kann). lange rede, kurzer sinn: es kann immer passieren, was nicht passieren darf.

um zu prüfen ob eine codeinjection möglich ist, habe ich folgende annahme getroffen: ein user hat es geschafft, sich unter dem namen
"<img src='1.jpg'>" bei der seite anzumelden. dieser name steht in der datenbank des servers (es ist also kein lokales problem eines users, sondern betrifft alle!).

des weiteren habe ich angenommen, dass serverseitig die übliche standardmethode benutzt wird, daten, die von usern stammen, vor der ausgabe mit der funktion htmlentities() zu behandeln, um codeinjections unschädlich zu machen.

beim aufruf der memberliste wird der name also nicht als "<img src='1.jpg'>" sondern als "&lt;img src='1.jpg'&gt;" ausgegeben.
dementsprechend kommt der html-code nicht zur ausführung. es wird der name angezeigt und nicht das bild 1.jpg geladen.

nun kommt aber js ins spiel. und der "übeltäter" ist die data eigenschaft (nicht etwa document.write). statt dem korrekten textknoteninhalt "&lt;img src='1.jpg'&gt;" gibt sie den html-code "<img src='1.jpg'>" zurück, der letztlich im popup eingefügt wird und zur ausführung gelangt, d.h. das bild wird angezeigt.

dieses verhalten zeigen bei mir firefox, opera und der ie.

anscheinend gibt es aber auch ausnahmen. innerHTML gibt, im unterschied zu data, bei allen drei browsern den inhalt des textknotens korrekt wieder!

@detleff:
zusammenfassend kingt das für mich recht konstruiert

zudie Methoden des node-Objekts geben das wieder, was im Dokumentenbaum ankommt, also auch nach der Auflösung der Entities.
innerHTML hingegen gibt einfach alles wieder, was im Quellcode steht und zwar insbesondere auch HTML-Code.

zur vermeintlichen Gefahr:
Schau dir die Scripte nochmals genau an: letztlich würde auch hier das "<img src='1.jpg'>" nur im value eines input-Elements auftauchen - also einer Stelle, die serverseitig widerum entschärft wird. Solange üsch sowas nicht per

document.write

oder

innerHTML

ausgibt passiert damit nix, denn nur so bekommst er das in den Elementenbaum.

zuüsch hat nie geschrieben, wie seine Datenbank zustande kommt.

Aber deine Bedenken lassen sich mit folgendem leicht entschärfen:

var wen = escape( ausloeser.firstChild.data.replace(/<|>/g,  " "));

(mit anderen Worten: ersetze alle kleiner/größer-Zeichen durch Leerzeichen)

ach so - für den Fall, dass sich jemand die Mühe macht, formular.htm durch direkte Eingabe in die Adresszeile aufzurufen (wozu auch immer), zusätzlich:

var wer = unescape( location.search.substr(1).replace(/<|>/g, " "));

ich habe nicht das gefühl, dass du den kern dessen, was ich meinte verstanden hast. seis drum.

So ist das mit den Gefühlen!

Aber nochmals mein Ansatz:

Ich gehe davon aus, dass üsch brauchbare Namen in seiner Namensdatenbank hat

ich verkompliziere die Problematik nicht durch Annahmen, die Datenbank enthielte bereits schadhafte Datensätze

mit der Variante der Datenübergabe zwischen Hauptseite und PopUp (escape und replace) kann kein HTML-Code in beiden JavaScripten auftauchen.

ich gehe davon aus, dass serverseitig eine sinnvolle Auswertung erfolgt.

mein Gefühl sagt mir, dass die JavaScript-Seite so sicher ist, wie JavaScript nun mal nur sein kann.

Zitat:
es kann immer passieren, was nicht passieren darf.

Wurst und Käse* wären hier: JavaScript ist deaktiviert. Dann passiert aber einfach gar nix. Inwiefern das schädlich ist, entzieht sich meiner Kenntnis. Frag doch mal üsch!

* "the worst case"