[Fswiki-dev] plugin処理部にXSS脆弱性

Back to archive index

HAYASHI, 'Lef' Tatsuya lef****@st*****
2003年 7月 15日 (火) 13:27:43 JST


Lefです。
すみません。あんま真面目に煮詰めきれてないので、
焦点のぼけたことを書いてると思いますが…。

On Tue, 15 Jul 2003 02:10:11 +0900
typer <typer****@cubic*****> wrote:

>> FSWikiの構造だと、サニタイズを各所でやらないといけなくてきついですよね。
>そっすね。プラグインでhtmlをじかに吐けるのは直感的だし、自由度が高いですが、
>サニタイジングやhtml以外の対応を考えると得策とはいえませんね。
>で、一つの策であるwikiフォーマットで書いてパーサへ投げるという形が直感的で
>ありながらサニタイズという面倒な事をやらなくてすむので好きです(笑)
>#が、効率はたしかに悪い。
ただ、現状だと、各pluginで同じようなデータを何度もパースしてたりして、
やっぱり効率はかなり落ちてるような気も。
同じような処理はまとめるというのは基本といえば基本かなあと。

あと、プラグイン側でサニタイジングということになると、
どうしてもプラグインの質に全体の安全性が左右されちゃうという
問題がでてくるかな、と。
僕は自分のサニタイジングに自信がないです(苦笑)。

プラグインのフレームワークをしっかりするという話ですかね。

>好みはさておき、PDF対応、他のwikiフォーマット対応やサニタイジングを考えると、
>そろそろパーサの設計を見直す時期かもしれません。
大したことのない経験と個人的な好みからすると、
やっぱりHTML部分は分離されてるといいかな、とは思ってます。MVC的な。
でも、HTML::Templateっていまいち使いがって悪いんですよね。
かといってHereDocもなあ…。

#脱線しますが、rubyのamritaはシンプルかつ汎用性高そうで魅力を感じてます

>以下思い付いたところで、
>・今のパーサを、構文解析・分離分割を行う本当の意味でパース主体の部分と、
> htmlやPDF生成の部分に分る。
>・プラグインは両者の間に入るドライバ的存在で、生成側のインターフェースを使ったり、
> パース側にもう一度わたしたりして出力を構成する。
>てな所ですが、大手術になりそう...
僕も似たようなことを考えてました。
もやもやとですが、上記のMVC的な考えで、プレゼンテーション層で
PDFやHTMLにする、というのと、
もう一方はApache2のmoduleみたいな構造(あれは規模でかすぎますが)で、
filter moduleとか動作ロジックの分割に合わせたハンドラーの設定とか。

しかしパーサーの設計はむずかしそうだ…。

>竹添さんのかんがえもおききしたいです。
是非。

-----
HAYASHI, "Lef" Tatsuya / mailto:lef****@st*****




Fswiki-dev メーリングリストの案内
Back to archive index