【PR】 アトピー関連商品比較 【PR】 マジックリスニングなど英語教材比較 【PR】 家電の安さ、品揃えに自信があります!! 【PR】 マジックトーカーズなど英語教材比較

文字コードとセキュリティ 【格安パソコンなら！ソーテックオンラインショップ！】 ここまで、いろいろな文字化けパターンについて考察してきました。これらの多くは（マイナー）ブラウザのバグによるもので、「仮に圧倒的多数であるWindows版IEユーザーがまともに見ることができるならば、他のブラウザで見た場合に多少文字化けしたところで、構わない」というスタンスもありえなくありませんでした。また、実際、そういうサイトも多いです。 ところが、実は文字コードの処理を誤ると思わぬセキュリティホールが起こりえます。代表的なものはクロスサイトスクリプティングです。クロスサイトスクリプティングについて簡単に説明しますと、ユーザー入力などにより動的に生成されるページがあったとします。 → 「田中　太郎」という入力値であれば問題ありませんが、「<font color=red><b>田中　太郎</b></font>」という入力値の場合、どうなるでしょうか？ もし、名前を表示する側のプログラムで適切な処理（HTMLタグやJavascriptコードの無効化。『サニタイジング』と呼びます。）を行っていなかった場合、そのままHTMLタグが実行されますので、赤い文字で名前が表示されます。これぐらいの話であれば、「裏技」ということで処理できるでしょうが、実際はセッション・ハイジャックなどの危険性があります。Javascriptもそのまま実行されるためです。クッキーを利用したセッション管理はよく見られる手法ですが、このHTMLタグの無効化処理の失敗による脆弱性を利用することで（クロスサイトスクリプティング Cross Site Scriptingと言います。略してCSS問題とも呼びますが、スタイルシートのCSSと紛らわしいので、XSS問題とも呼びます。）、他人のクッキーを盗み出すことが可能です。 何も知らないユーザーAが、悪意のあるユーザーBが巧妙に仕組んだURLをクリックすると、そのサイトで発行されているクッキーが、Bの管理するリモート・サーバに送信させることが可能になるのです。仮にクッキーだけで認証しているとするならば、後は、Bは自力でそのクッキーを焼いて、そのサイトにアクセスすれば、Aになりすますことが可能になります。詳しくは、下記のサイトを参照してください。 （参照）▼ IPA ISEC　セキュア・プログラミング講座 http://www.ipa.go.jp/security/awareness/vendor/programming/ IPA（情報処理振興事業協会）のまとめ。プログラマー必読です。 タグ 対策後 < &lt; > &gt; & &amp; " &quot; では、このHTMLタグの無効化（サニタイジング）はどうすればいいかといいますと、皆さんご存知のように、左の表のように置換すれば良いことになります。これは、下記のような文字化け を悪用した攻撃にも効果的です。 例えば、「<」は16進文字コードで「0x3C」です。確かに、「<」で表示される文字（１バイト）なら、Shift_JISでもEUC-JPでもJISでも文字コードは一緒でしょう。しかし、もし「0x3C」を2バイト文字（漢字）の一部であると解釈すればどうでしょうか？ Shift_JISやEUC-JPには幸い「0x3C」は現れませんが、JISには現れます。 例えば、「紗」という漢字は、Shift_JISでは0x8ED1ですが、JISでは0x3C53です。0x3C53は、Shift_JISやEUC-JPでは、「1バイト文字が二つある」としか解釈できまず、この場合、「0x3C=<」「0x53=S」となります。つまり、JISコードの「紗」がShift_JISやEUC-JPと解釈されると、「<S」と文字化け  します。 JISコードでPOSTするのはいとも簡単です。元もとの入力フォームがShift_JISであったにせよEUC-JPであったにせよ、それをローカルに保存する際にJISで保存します。保存したファイルのメタタグをJIS（ISO-2022-JP）に書き換え、formタグのaction先をhttp〜に書き換えればJISコードでPOSTできてしまいます。ユーザーからのデータ入力が、こちらが想定したページからの送信であるという保証はありません。refererのチェックも対処策の一つですが、refererは偽造が容易である上に、Norton Internet Securityなどの製品を使っている善意のユーザーをはじく可能性があり、あまりお薦めできません。 攻撃者は、JISでPOSTできる仕組みを準備できたら、後は、EUC-JPとして解釈した場合に「<SCRIPT>〜」となるような、巧妙に仕組まれた文字列（JIS漢字の文字列。日本語としては成立していないような文字列だが、EUC-JPと解釈された場合、危険なコードになるようなもの）を人為的に作成します。それをJISコードのフォームからPOSTすれば　入力された元の文字列（漢字）には「<」「>」の影も形も無いように見えても、実際には危険なコードが隠されていることになります。EUC-JPのデータが飛んでくるものと思い込み、サニタイジングすることなく、EUC-JPとしてそれを解釈した場合、タグが実行される危険性があるのです。 ただ、私がテストした限りでは、例えばPHPのhtmlspecialchars関数でも、perlでもサニタイジングさえしてあれば、この文字化けを悪用した攻撃（実行させたい文字列をわざとJISコードに文字化けさせたものを予め作成し、それを送信するという攻撃。サンプルをお見せすれば、何を話しているのかより分かると思いますが、悪用されると困るので公開は控えます。）に対してもタグを無効化できました。 とは言いつつも、もしかするとサニタイジングでも危険性が残っているかもしれないので、想定外の文字コードでデータが飛んできた場合は、一律にエラーにするという処理でも良いように思います。PHPならmb_detect_encodingで文字コードの取得は可能でしょうし、perlならjcode.plを利用しても可能です。ブラウザの中には、さまざまな挙動をするものがあり、善意のユーザーに迷惑をかけてしまうかもしれませんが、こんなことは滅多に起きません。例えば直前のページの文字コードを引きずってしまうというバグを持つブラウザもあり、その場合、こちらが想定している文字コード以外の文字コードでPOSTされる可能性もなきにしもあらずですが、「セキュリティ上の理由で、想定外の文字コードでPOSTされた場合、一律エラーにさせていただいています」でも良いのではと私見ですが、思います。 この２バイト文字におけるクロスサイトスクリプティングの危険性については、下記の文書が英語ですが、一番端的に語っていると思います。 （参照）▼ Understanding Malicious Content Mitigation for Web Developers http://www.cert.org/tech_tips/malicious_code_mitigation.html CERTの報告（英語）。「Explicitly Setting the Character Encoding（明示的に文字コードを指定する）」ことなどを、クロスサイトスクリプティング対策として掲げています。 そして、まさしく、このような文字化け を悪用したクロスサイトスクリプティングを防止するための処置が、善意のサイトの文字化けの遠因にもなっていることを説明したのが、「.htaccessによる認証の後、ネスケ4.Xで文字化けする」の章でした。 このように文字コードとセキュリティという、一見関係のないように見えるものが、実は、重大な問題で関係しているのです。この章でWebmasterのための文字化け講座は終わりですが、付録として、次のページで、本ホームページで利用したFlashツール（機種依存文字チェッカーやURLエンコーダー）をダウンロードできます。