[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-users:33051] Re: [FAQ] /usr/share/doc/ の日本語 html 文書と apache (>=1.3.12)



池田@オレンジです。

On Mon, 20 May 2002 22:37:57 +0900
in [debian-users:33041] Re: [FAQ] /usr/share/doc/ の日本語 html 文書と apache (>=1.3.12)
MATSUDA Yoh-ichi / 松田陽一 <matsuda@xxxxxxxxxxxx> Wrote
> こんにちは。松田陽一@PAL-NET三鷹です。

> 一見文字化けに見える文字列が、実は悪意あるコードであり、文字コー
> ド指定で隠すことができちゃうんですね。

というか、日本語としては意味を成さないけど、ISO-2022-JPとしては正しい文
字列が、文字コード解釈を間違えると単に文字化けするだけでなく、別の意味の
あるコードとなってしまう可能性があるという事ですね。

ISO-2022-JPとして解釈されている限りにおいては、それは「日本語として意味
不明な文字列」であって、そのコードが実行される事はありませんので「文字コー
ド指定で隠す」というのはちょっと違うような感じがします。

> [疑問その1]
> ということは、 iso-2022-* 系はクロスサイトスクリプティング脆弱性
> の要因を抱えた仕様である、と解釈できるでしょうか?

極論すればそう言えるのかもしれません。

> [疑問その2]
> http レスポンスの際に MIME ヘッダで charset を設定すること、そ
> して逆に html の meta タグは不要であると主張する意見が、
> 
>    リンク名 charsetパラメタの勧め: HTMLにおける文字符号化スキームの明示方法
>         URL:
>           http://www.fxis.co.jp/DMS/sgml/xml/saloon/html_correct_charset.html
> 
>    リンク名 Redirect 後表示するhtml のcharset
>         URL:
>           http://mm.apache.or.jp/pipermail/apache00-01/2000-March/000258.html
> 
> 等で見られます。

どちらも「METAタグ不要」と言うより「METAタグだけでは不十分。charsetを正
しく指定しよう」という主張に見えますが...

もっとも、上の文書で

http://www.fxis.co.jp/DMS/sgml/xml/saloon/html_correct_charset.html
> METAタグによるcharsetの指定は、proxy serverによるコード変換があれば機能
> しません。実際、DeleGateサーバによるコード変換によってMETAタグ中の
> charset指定が不正になれば、文字化けを起こします。proxy serverが METAタグ
> も書き換えればいいという意見もあるかと思いますが、本来proxyは HTML文書を
> 書き換えるべきではありません。

とも書かれていますが、HTML文書をビット列として考えた場合、文字コード変換
をする事によって既に「HTML文書を書き換えている」のですから今更METAタグの
書き換えを躊躇する理由にはならないと思いますし、そもそも勝手に弄って変に
なったのなら弄ったヤツが責任持つべきでそれを元の文書に転嫁するのはいかが
なものかと...

# 何か政治家みたいな発言だなぁ(^^;

他には積極的にMETAタグを書かない方がいいという事は書かれていないように見
受けます。

> 長いこと html で meta タグを書き続けて来た自分にとって、どちら
> がよいのか、わからなくなって来ました。
> meta タグは止めるべきなのでしょうか。

という事で、「METAタグ書いて、charsetも正しく指定する」のが良いのかもし
れません。

ただ、「AddTypeでcharset指定すればOK」というのも場合によりけりかもしれま
せん。

たとえば、既存の色々な文字コードが混在しているディレクトリがある場合とか
には、単に.htaccessでcharset指定する訳にも行きませんし...

流石に「ウチの/any/where/ディレクトリにはISO-2022-JPもEUC-JPもShift-JIS
も何でもあるぜぃ」という人はまれでしょうが、自分の作った文書はEUC-JPで統
一してるけど、同じディレクトリにあるどこかから持ってきたCGIはISO-2022-JP
というような事はままあるでしょうし、英語文書の和訳なんかやってるような場
合には、同一ディレクトリに元のISO-8859-1文書と、和訳したISO-2022-JP文書
があるという場合もありますね。

ISO-8859-1文書のContent-typeをISO-2022-JPとしてしまっても、(誤った
charset解釈によるクロスサイトスクリプト脆弱性を引き起こすという意味での)
実害はありませんが、「charsetを正しく指定しましょう」という本来の意味か
ら言えば「誤った指定」とも言えるかもしれません(ISO-8859-1の元文書にMETA
タグでISO-8859-1と指定されていれば明確に誤りです)。

そもそも、文書単位で違う可能性のある文字コードをディレクトリ単位でしか指
定できないというのがちょっと不十分な気がします。
ここはやはりMETAタグを解釈してcharsetを付けて欲しいですね。 

--

Masaki Ikeda <masaki@xxxxxxxxxxxx>
    Orange System Co.