何故かあたり前にならない文字エンコーディングバリデーション

(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに

[ockeghem]

『誤字・脱字では自分でも見つけましたが、こういう本の評価に重要なのでしょうか？』<重要。斜め読みで誤報しない、サンプルを動作確認する、なども重要/日記書いた『既にあたり前になりつつある…』http://bit.ly/qVLlB

[ardarim]

「誤字・脱字では自分でも見つけましたが、こういう本の評価に重要なのでしょうか？」 信頼性が低く見られる。ちゃんと推敲されてないってことだから。「書く事だけに一生懸命」とか時間がないとかは言訳にできない

[Kiske]

読み手のこと考えると誤字・脱字は無い方がいいでしょ。

[ghostbass]

やる場所でいえば$_GETとかに詰め込まれる前段階だよなあ。

[hnw]

mb_check_encodingはSJIS-win/eucJP-winのとき正しい文字を不正とみなすので、イマイチ使いにくい気がします。UTF-8ならいいかもしれませんが。参考： http://d.hatena.ne.jp/hnw/20090215/

[fukken]

実装は容易。困難とか言ってる奴はコードと脳の両方、もしくは脳が腐っている。問題は性能にどう響くか、だけど、仕方ないコストだよねぇ//一番腐っているのはブラウザと処理系だが

[nihen]

大筋同意なんだけど、「Ruby1.9は不正な文字エンコーディングを受け付けないからです。個人的には明示的にバリデーションコードで検出する方が良いと考えています」の理由を知りたいです

[rryu]

私も当たり前の対策の一つになると思っていたが、ならなかったのはMBCSでは結局必要となる文字コード変換がその替わりになる、冗長なUTF8はブラウザ等が拒否すれば影響がないのでXSSCSSのようにスルーされたのではないか

[kgbu]

耳イタすぎ。あたりまえにならないからといって手を抜く理由にならんぜ＞自分

[mumincacao]

mysql_set_charset() は 5.2 系からじゃないと使えないからさ～ばによっては SET NAMES しかできないこともあるにう（´・ω・｀；【みかん　そ～いえば，mb_check_encoding() ってどこかのば～ぢょんで誤動作しなかったっけ？

[lovely]

あとで

[paella]

必読。2009/9/10夕方からTwitterで色々質問させてもらったことの、まとめのような内容になっている。

[ikepyon]

文字コードのチェックは仕様とは関係ないから実装されないんじゃないかな？やるのだったらPHP側で出来るだろうし、すべきだと思う。

[MinazukiBakera]

うーむ。チェックしろと口で言うのは簡単だけど実装はそんなに簡単じゃない、という話もありそうですけどね。

[IwamotoTakashi]

SQLを組み立てたりHTMLを出力したりするときに弾けばいいので、入口で弾く必要はないと思ってます。

[americanboss]

具体的な例示がないと、誰も危機感持たないよ。XSSだとかSQLインジェクションとかはわかりやすかったから対策ブームが起きたわけで。「文字エンコーディングバリデーション」なんてネーミングじゃ流行らない……

[tohokuaiki]

ohgakiさんの文章は、正確なんだろうけど、どーも凡グラマの自分には読みずらい・・・。

[sylvan_l]

文字エンコード文字化け

[hasegawayosuke]

「ブラウザの文字エンコーディングの自動認識を「オフ」にすれば、かなりリスクを軽減」 ＜ あんまりかわらん。「文字エンコーディングをバリデーション」とか意味通りにくい書き方せずにもっとわかりやすく書けばい