Mal weg von Spammer und Werbern hin zu unserem Wiki.

Auf der Diskussionsseite zum Sample habe ich mit Coolcat kurz zum Thema "Ideen für die Integration von WebGL ins Wiki" gesprochen.

Ich will die Diskussion gern hier im Forum im größeren Kreis fortsetzen. Hier der Stand:









Wer hat da Ideen. Eventuell in Verbingung mit einem DGL CMS? WebGL birgt potential um das Thema "Modernisierung der DGL System (aka "NextDGL")" nochmal anzukurbeln.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich weis nicht ob ich dich richtig verstanden habe auber ich fände diese Idee toll. Ich versuche im Moment einen kleinen JS-Debugger für die wichtigsten Befehle in WebGL zu schreiben, da die Fehlermeldungen manchmal nicht so hilfreich sind. Außerdem könnte man zB. hier im Forum eventuell einen Interperter schreiben der in einem Fenster das Programm vom User selber ausführt und im anderen die Zeile anzeigt die gerade ausgeführt wird, etc.

_________________
You even trying ...

Website: http://rise-of-light.de/

Inhalte im Wiki und "DGL CMS":
Wie das mit einer Upload-Beschränkung ist weiss ich nicht. Dazu würde ich empfehlen, mal nach einer Erweiterung fürs Wiki zu suchen die sowas kann. Und das DGL-CMS ... erstmal das Forum Upgrade. Dann kann man über mehr reden.

OT: Für Javascript-Debugging kann ich die Firefox-Erweiterung Firebug empfehlen. Die hat einen JS-Debugger integriert.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Serverseitig gibt es kein Risiko, da das ganze auf Clientseite herunter geladen und anschliessend ausgeführt wird. Der Browser holt sich über GET die Datein und führt die html5+js files aus. Was allerdings auf Clientseite so gemacht werden kann ist Sache von FireFox, Safari, Opera, IE und wie sie alle heissen.

Ich denke, dass für die Thematik kein extra Unterforum notwendig ist, da viel zu wenig interesse da ist. Im Prinzip ist das wie bei OpenGL3, viele interessieren sich für aber wenige arbeiten mit(viele Konsumer und wenige Producer).

Vor einiger Zeit hatte ich mich auch mit WebGL beschäftigt und ich denke das wir noch ne menge Freude an den Thema haben werden. Schade nur, dass JavaScript und die XML, JSON, HTML,... Parser nicht gerade gleich schnell unter verschiedenen Browsersystemen sind :\
Als ich mir meine eigene C++ Matrix und Vektorklassen nach JS portiert hatte lief das auch problemlos aber Geschwindigkeit und syntax sind schrecklich. Vieleicht kann man da noch irgendwas auf Serverseite Löten, da php ja ne schöne dynamic library support hat und eigene so files schreiben ist ja mit c und c++ ein kinderspiel und sehr performant.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Nun das JavaScript auf der Clientseite ausgeführt wird, war mir dann doch irgendwie klar. Vielmehr interessiert es mich eben doch, welches Gefährungspotenzial insbesondere auf Clientseite möglich ist. Insbesondere ob dieses höher ist als eine reine Aktivierung von JS. Sollte dies nicht sein, würde ich die Gefahr als relativ gering Einstufen. Wer mit JS im Netz unterwegs ist, ist sich den Risiken hoffentlich bewusst. Das Editieren im Wiki ist nur Gruppenmitgliedern möglich, so dass dies zumindest einmal kurz gezeigt haben, dass sie a) in der Lage sind das Wiki zu lesen und b) halbwegs wie ein Mensch schreiben. Sollte dort wirklich ein Gefährder dabei sein, sollte man diesen relativ fix ausfindig und sperren können. Der Aufwand hierfür ist für die Massenspamer viel zu hoch... handelt es sich um ein Individuum, dass nur aus Spaß ein wenig Schaden anrichten will... ich erstatte auch gegen anonym mit den Verbindungsdaten Anzeige. Von daher wäre das Wiki vermutlich in Bezug auf WebGL ein besserer Ort als z.B. das Forum. Ich werde mal prüfen, ob es ein Freigabesystem für Namespaces gibt. In einem solchen Fall sollte sich aber auch jemand finden, der mit WebGL dann wirklich vertraut ist und die Reviews machen könnte, da es sonst kaum etwas bringt.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Es könnte jemanden beliebigen JavaScript Code bei Leuten ausführen die die Seite betrachten.

Beispiel 1:
Der JS-Code liest das DelphiGL-Cookie aus uns schickt dieses via HTTP-GET an seinen Heimatserver. Angenommen das Opfer war ein Admin, dann kann sich der Hacker nun mit Adminrechten einloggen.

Beispiel 2:
Der JavaScript-Code platziert ein Seitenfüllendes IFrame über der normalen Webseite. In diesem IFrame wird wieder das Wiki geladen, es wird aber die Login-Seite gezeigt. Einmal nicht nachgedacht => Passwort mitgelesen und an den Heimatserver geschickt. Mit dem Adminpasswort kann er jetzt sogar das Passwort und die EMail ändern => ausgesperrt.

Beispiel 3:
Die Idee von Beispiel 2 könnte möglicherweise auch mit anderen Seiten funktionieren. (bin mir gerade nicht sicher ob das geht....möglicherweise schützt NoScript)

...und das nur wenn ich 5min darüber nachdenke...und ich bin kein JavaScript-Experte. Beliebigen Code ausführen dürfen ist immer schlecht. Sogar mit HTML alleine kann man schon Unfug anstellen soweit ich weiß.

_________________
Yeah!

Ich denke es wird sowieso nur sehr wenige Samples geben. Wir schon vor mir vorgeschlagen...ein einfacher Ordner und ein Admin lädt das hoch, fertig. Für meine nächsten Samples wird das wahrscheinlich sowieso nicht anderes gehen, da die alle mit GWT gemacht sind. Wenn dann auch noch AJAX dazu kommt muss eh ein Tomcat im Hintergrund laufen.


Bei einem Mediawiki mit Standardeinstellungen nicht. Es ist zwar möglich HTML-Code im normalen Wiki-Text zu benutzen, beispielsweise "<br />", aber das ist nach meinem Wissen eine sehr begrenzte Whitelist. Wenn da aber jemand Custom-Tags fabriziert hat bei denen man HTML-Code einfügen kann der dann auch wirklich ausgeführt wird, wäre es wahrscheinlich möglich. Dazu müsste man aber Wissen was es den überhaupt für Tags gibt

_________________
Yeah!

@JS Gefahren: GET/POST Aufrufe an fremde Domains sollte der Browser normalerweise verhindern. Jedenfalls ist mir keine legale Möglichkeit bekannt (JS Proxys ausgenommen) die sowas ermöglichen.

Genauso die IFrame Geschichte. Zwar kann das Cookie ein IFrame erzeugen, aber es selbst hat keinen Zugriff auf die IFrame Inhalte und das IFrame genauso wenig auf die Inhalte seines Erzeugers. Da setzen einem die XSS Sperren der Browser einen Riegel vor. Unter Umständen geht es, wenn die Domains identisch sind.

@3D im Web: Finde es für kleinere Dinge nicht schlecht, aber für größere Applikationen werden denke ich weiterhin Applets mit nativer Anbindung an GL und Flash Objekte genutzt werden. Da ist man wesentlich weniger limitiert was die Features angeht.

_________________
(\__/)
(='.'=)
(")_(")

Das geht ganz leicht...du bindest ein 1x1 Pixel Bild ein und codierst die Daten als GET in die URL.


Das geht, siehe:
http://www.dyn-web.com/tutorials/iframes/refs.php

_________________
Yeah!

Naja, du gehst in deinem Fallbeispiel davon aus, das du von der Quellseite auf das IFrame zugreifst. Das dies möglich ist sollte eigentlich klar sein. Denn die Seite ist der Besitzer des IFrames und hat somit Zugriff. Aber die Seite die im IFrame dargestellt wird, hat keinerlei Zugriff auf die Website von der sie erzeugt wurde. Das löst eine XSS Exception aus.

Das stand in deinem verlinkten Artikel übrigens auch drin.


Und in aller Regel nutzt man IFrames nur, wenn man CrossDomain Inhalte anzeigen will. Und da nützt einem das HTTP Cookie herzlich wenig. Abbhilfe würde da ein FlashCookie bieten, das bekanntlich von überall gelesen werden kann.

Oder wir reden gerade beide von zwei verschiedenen Szenarios.

_________________
(\__/)
(='.'=)
(")_(")

Die Gefahr ist ja gerade das der JavaScript Code im Context von http://www.delphigl.com ausgeführt wird. Das Skript kann in aller Ruhe Daten sammeln und diese dann wie beschrieben über die Einbindung eines Bildes an einen anderen Server schicken.

Nur Beispiel 3 würde dann wohl nicht funktionieren, zumindest nicht ohne irgendwelche Sicherheitslücken im Browser zu nutzen.

_________________
Yeah!

Aber die Gefahr hast du bei jedem Skript das du von einem Anbieter einbindest. Anders könnten GoogleAnalyzer, Piwik und Co gar nicht funktionieren.

Notfalls müsste man bei diesem WebGL JS Skripten jemanden den Code zuvor sichten lassen oder gänzlich darauf verzichten. Denn man ist mit OpenGL ES schon stark eingeschränkt im direkten Vergleich zu Anwendungen die den vollen OpenGL Umfrang via Browser gewährleisten. Zb. LWJGL, JOGL, Ogre, etc

_________________
(\__/)
(='.'=)
(")_(")

Also ganz klar ist, die Skripte dürfen nicht ungesichtet aktiviert werden. Denn dann kann einfach zu viel Unfug betrieben werden. Ohne jetzt irgendjemanden irgendetwas zu unterstellen, es kann ja auch immer mal sein, dass ein Account außer Kontrolle gerät (nicht jedermanns Passwort wird zufallsgeneriert und nur genau für DGL verwendet sein und nirgendwo aufgeschrieben etc.). Die Sichtung vielleicht auch gleich von zwei bis vier Leuten, um sicherzustellen, dass auch subtilere Angriffe nicht durchkommen.
Kann man das irgendwie recht einfach im Wiki lösen, frage ich mich? Bisher werden Script-Tags ja anscheinend abgefangen. Sie werden Plaintext dargestellt. Das heißt, dass man sie mit einer Erweiterung problemlos hooken kann. Vielleicht kann sich ja jemand mit etwas mehr Erfahrung mit Mediawiki-Erweiterungen mal damit auseinandersetzen. Ich stelle mir gerade sowas vor, wie es das seit einiger Zeit zumindest in der Deutschen Wikipedia gibt. Dieses Gesichtet/Nicht gesichtet. Auf Gesichtet setzen könnten dafür ausgewählte "JS-Kenner" und nur bei Seitenversionen, die auf Gesichtet gesetzt wurden, werden Scripts ausführbar wiedergegeben.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also das "Gesichtet-Flag" gibts bei uns auch schon. Aber ob man daran eine Auswertung hängen kann, weiß ich net.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich weise nochmal darauf hin:

• nicht jede WebGL Anwendung ist so klein das man sie bequem in einen Wiki-Tag stecken kann. Insbesondere könnte eine WebGL-Anwendung verschiedene Libraries benutzen, z.B. WebGLU oder die Mathelib Sylvester. Auch eine mit GWT compilierte Anwendung besteht aus ca. 10 Dateien.
• die WebGL Anwendungen benötigen Shader, Texturen und Meshdaten. Da in WebGL auch Videotexturen möglich sind (*), möglicherweise auch Videos.
• es wird hier im Wiki nur einige wenige Samples geben. Der Aufwand um die ersten beiden Punkte im Wiki möglich zu machen ist in Relation zum Nutzen einfach zu groß.

Was spricht gegen einen simplen Ordner. Wer ein Sample hat schickt das an einen Admin, der das dann hochlädt. Implementierungsaufwand = 0

(*) habs mittlerweile ausprobiert

_________________
Yeah!