Du hast natürlich Recht - diese Option haben wir schon vor dem Release von cpg1.4.21 in Erwägung gezogen: einfach das Problem zu einem Problem für den Benutzer erklären. Aber mal ehrlich: welcher Benutzer liest Sicherheitswarnungen? Welcher Benutzer versteht, was bei einer
CSRF mit Hilfe eines Bildes (ganz gleich ob per
<img>-Tag in HTML oder eine Ebene abstrakter per bbcode-Tag
[ i m g ]) vor sich geht? Welcher Benutzer kann abschätzen, ob er dieses Risiko eingehen möchte oder nicht? Mehr als 10% aller Benutzer? Mit Sicherheit nicht. Wenn Du so willst ist das schon ein bißchen Bevormundung, was wir hier treiben: wir zwingen die Benutzer zu mehr Sicherheit. Wer unbedingt das Risiko eingehen will, das vom Zulassen der bbcodes
[ u r l ] und
[ i m g ] ausgeht, dem haben wir ja in der Doku einen Weg beschrieben und ausführlich den zu reaktivierenden Code mit Kommentaren versehen. Wer nämlich zu den 10 % gehört derjenigen, die wissen oder zumindest wissen wollen, was CSRF ist, der kann auch ein paar Zeilen im Quellcode wieder einkommentieren und dann mit den Konsequenzen in der Regel ganz gut leben.
Die Fraktion der Nie-das-Handbuch-Leser wird jedoch blindlings alle Optionen aktivieren, die sich nach "mehr Features = Besser" anhört. Wenn ihnen dann aber ein böser Bube das Fell über die Ohren zieht sind diese Personen die ersten, die dann in einem Anflug von Halbwissen in allen verfügbaren News-Kanälen brüllen, wie unsicher eine Applikation denn sei. Ich denke, dass das PragmaMx-Team dieses Problem nur zu Genüge kennt alleine schon durch die leidvolle Vergangenheit, in der die Nuke-Portale der ersten Stunde nicht unbedingt die besten Kritiken bekommen haben, was Sicherheit angeht.
Also: voraussichtlich keine bbcode-Tags in Kommentaren (am besten überhaupt keine mehr, auch keine Fettschrift oder ähnliches). Möglicherweise keine
[ i m g ]-Tags mehr in Beschreibungen. Mit ziemlicher Sicherheit aber werden
[ u r l ]-Tags wieder zurückkehren, möglicherweise aber mit Einschränkungen. So wäre es durchaus denkbar, dass nur relative Links innerhalb der Domäne erlaubt sind, auf der die Galerie läuft. Denkbar ist auch ein Rechte-System für die bbcode Tags, so dass der Admin sie für sich selbst erlauben und für alle anderen verbieten kann.
Um aber diese Diskussion auf eine breitere Basis zu stellen bitte ich an dieser Stelle darum, die Diskussion hier auf Deutsch einzustellen: nur drei der Entwickler sprechen Deutsch. Die gemeinsame Sprache der Entwickler ist Englisch. Wer also an der Entscheidung teilhaben möchte, der möge sich doch im internationalen Forum an entsprechenden Diskussionen beteiligen, da ich nicht bereit bin, das Übersetzerlein für solche Debatten zu spielen.
Joachim
P.S. Zum Thema "Barrierefreiheit" möchte ich noch anmerken, dass in der Tat die derzeitige Praxis mit Pop-Ups nicht unbedingt der Gipfel der Technik ist. Daran wird auch cpg1.5.x leider nicht sehr viel ändern - auch dort sind die Hilfe-Texte immer noch als Pop-Ups realisiert. Eine vernünftige Inline-Hilfe, die auch Barriere-Freiheit aureichend würdigt (d.h. die auch auf Screenreadern, Braille-Geräten etc. läuft) würde außerdem einen weitreichenden Verzicht auf JavaScript notwendig machen. Das hiese aber, zugunsten der Benutzer mit Handicap der Masse der Benutzer mit "normalen" Browsern eine Menge Komfort-Funktionen zu nehmen. Den Sinn dahinter sehe ich nicht so ganz, denn seien wir mal ehrlich: Coppermine ist in erster Linie eine Bildergalerie - welcher stark Sehbehinderte Benutzer, der auf ein Braille-Lesegerät angewiesen ist legt gesteigerten Wert darauf, eine Coppermine-Galerie bedienen zu können, wo er doch die Bilder nicht sehen kann, die unvermeidlicherweise der Kern einer Coppermine-Bildergalerie sind. Der Trend geht Richtung JavaScript-Einsatz (Stichwort "Ajax"). Diesem Trend können und wollen wir uns nicht verschliessen.
Author
Topic: Ist bbcode unter bestimmten Voraussetzungen unbedenklich? (Read 5495 times)