ただただしです。
「識者」って書いたのは「識者がいてくれたらいいなぁ」程度の希望なので、あ
んまり気にしなくていいです。すみません。まぁ、例によって少ないリソースで
解決しなくてはいけないので、理論的バックグラウンドがあると助かるんですが。
Hideki SAKAMOTO <hs@on-sky.net> wrote:
>上に挙げた日記の記述から，Refererというのは「リンク元」のことと
>解釈しました．で，坂本さんは「リンク元の表示でtDiryがEUCと
>Shift_JIS混じりの出力をするためw3m-m17nで文字化けが生じる」と主
>張しているようですが，この解釈からして間違ってませんでしょうか?
坂本さんはそうおっしゃってます。私も事例をつきとめたわけではないのですが。
>これらを見る限りtDiaryがEUCとSJIS混じりの出力を行う
>ことはないと思います．にもかかわらず文字化けが起こるということは，
>・w3m-m17nの漢字コード判定ルーチンが間違いを起こす．
>・Rubyのto_eucメソッドが間違いを起こす．
>のどちらかなんじゃないかと思うのですが，いかがでしょうか？
まずto_euc(NKFモジュール使用)が、与えられた文字列の文字コードを誤認識す
る可能性はあります。refererに含まれる日本語は短いので、判定をミスってし
まい、EUCにしたつもりが結果的にSJISの断片になる……ということはあるかも
知れません(未検証)。
さらに、disp_referrer.rbやreferer-utf8.rbはuconvを使っているので、別の状
況もあり得ます。
あと、w3m-m17nは(伝聞ですが)、内部的には1行単位でiso-2022-jp化しているそ
うなので、「入力文字列→iso-2022-jp→表示コード」のどこかで判定ミスをす
ることはあり得ます。
いずれにしても、tDiary側でEUC化後のreferer文字列に不正な文字コードが含ま
れていたらエスケープする、というのはアリだと思います。これを実現する確実
な手法があるかどうか、よくわかっていません(単にCGI:::escapeHTMLすればい
いのかなぁ?)。
>これについては，tDiaryで対処しても良いかとは思いますが，このパタ
>ーンをw3m-m17nが上の記述にあるように間違えて解釈し，XSSが起きる
>ということは，tDiary以外のCGI等でも上のパターンを故意に埋め込め
>れば，同様にXSSが起きる可能性はあるわけで，本質的にはw3m-m17n側
>を直さないといけない問題だと思います．
これは坂本さんとも協議(?)しようと思っているんですが、w3m-m17nでは複数の
エンコーディングが混じった文書も正しく表示しようとしている(だから1行単位
で判定し、charsetも無視する)ようなので、個人的にはw3m-m17nサイドの問題だ
よなぁ、と感じています。まぁ、コントロールコードを落とすくらいはたいした
手間ではないかも知れないですけど。
━━━━━━━━━━━━━━━━━━━
ただただし <http://www.spc.gr.jp/sho/>
♪ツッコミは、短く鋭く愛を込めて。
━━━━━━━━━━━━━━━━━━━
|