Lieber 1UnitedPower,

vielen Dank, dass Du diesen Sicherheitsaspekt in diesem frühen Stadium schon in den Vordergrund stellst. Man macht sich manchmal darüber zu wenige Gedanken.

Sind unsere Wiki-Beispiele alle so bösartig geschrieben, dass sich damit XSS-Angriffe durchführen lassen?

Wer weiß, unser Wiki erlaubt auch unangemeldeten Benutzern Artikel zu schreiben und zu bearbeiten. Wer Lust darauf hat, der könnte so einen Angriff problemlos starten.

Das würde bedeuten, dass ich mich von der Idee verabschieden muss, einfach eine Wiki-Seite nach Beispielen zu parsen, um diese dann in ein Fiddle zu laden. Das Fiddle kann dann nur "echte" Beispiele parsen, die als eigenständige HTML-Dokumente ins Wiki hochgeladen wurden. Das würde die Sicherheit wesentlich steigern.

Und wenn wir schon eine JavaScript-Spielweise bauen, dann sollten wir auch direkt das volle Potenzial ausschöpfen und keine exklusive Lösung für das Wiki bauen, sondern gleich auch an das Forum denken.

Warum sollten wir das? Eine Forumsfrage darf gerne auf externe Anbieter wie jsFiddle zurückgreifen. Wenn einmal im Forumsarchiv die Links zu den Fiddles nicht mehr funzen[tm], dann ist das meiner Meinung nach verschmerzbar. Bei den Wiki-Beispielen ist es das nicht.

"allow-same-origin" darf nicht gesetzt sein, wenn wir den Fiddle-Server unter der selben Domain wie das Wiki betreiben, denn das würde dem Skript erlauben aus der Sandbox auszubrechen. Allerdings wird vom w3c sowieso empfohlen, dass die iframe-URL auf eine andere Domain verweist. In diesem Fall wäre "allow-same-origin" wieder sinnvoll und ich meine auch ungefährlich.

Mein Code erstellt das Iframe-Element dynamisch: <iframe src="about:new" /> Es sollte also unter der entsprechenden Domain gelten. Und wenn man nichts weiter angibt, dann sollte JavaScript doch seine Same-Origin-Policy anwenden, oder nicht? Damit sind Fremdscripte ausgeschlossen. Und das finde ich prima!

Ich habe ehrlichgesagt ganz schön Bauchschmerzen, wenn ich daran denke, so ein Fiddle-Dingsbums selber zu entwickeln.

Du willst ja auch jsFiddle "klonen". Das will ich nicht. Wir könnten die redaktionelle Arbeit nicht leisten, um sicherzustellen, dass User dort keinen Müll posten.

Versteh ich mich nicht falsch, ich bin auch sehr dafür, dass wir unser Wiki mit so einer Online-Spielwiese bereichern, ich will nur dazu mahnen, dass wir uns das genau überlegen, bevor wir etwas überstürzen, das uns später enorme Schwierigkeiten einbringen kann.

Da verstehe ich Dich - glaube ich - völlig richtig. Better safe than sorry.

Allen voran möchte ich mal die Frage in den Raum stellen, ob wir bei SELFHTML überhaupt die nötige Expertise aufbringen können, um so einen Service selber zu entwickeln und zu betreiben. Ich bin nicht davon überzeugt und würde doch lieber auf einen Dirttanbieter setzen.

Sollten wir einen Dienst anbieten wollen, genau so wie ihn jsFiddle bereitstellt, dann stimme ich für ein klares "no go!". In meinem OP hatte ich ja ganz klar umrissen, dass ich mich ganz streng auf Wiki-Beispiele beschränken will (siehe fehlender "speichern"-Button). Wenn das Fiddle außerdem nur offizielle Beispieldokumente verarbeiten kann, die ausschließlich von dazu berechtigten Autoren erstellt und hochgeladen werden können, dann sollte der Sicherheitsaspekt einigermaßen gefrühstückt sein.

Oder wüsste da jemand noch weitere Aspekte zu?

Liebe Grüße,

Felix Riesterer.