UTF-8 エンコーディングの危険性 - WebOS Goodies - 葉っぱ日記
UTF-8の非最小形式による代替エンコーディングの話。古典的な攻撃方法なので、知っていて当然の話だと思っていたのですが、意外にまだ知られていないんですね。古くは Nimda の攻撃でも利用されていました…というのを調べていたら、たまたま「セキュリティホールのアンチパターン」という資料がひっかかったので紹介しておきます。あとは、ばけらさんによる説明「用語「Unicode Web Traversal」@鳩丸ぐろっさり (用語集)」がわかりやすいです。 個人的には、「UTF-8」というからには、こういうおかしなバイト列が含まれていた時点で入力全てを捨ててしまって例外などを発生させるべきで、無理やり UTF-32 とかに直すのは間違っているように思います。そうでないと、0xC0 0x32 のように、完全に壊れている UTF-8 をどうするの？とかにもなりますし。 あと、どうでもよい話： そもそもU
UTF-8 エンコーディングの危険性の補足 - WebOS Goodies
えー、昨日投稿した「UTF-8 エンコーディングの危険性」の記事ですが、なにを間違ったのか過去最高のアクセスを記録しています。その前の Ruby 用 JSON クラスの反響がさほどでもなく、今回も大したことないだろうと思っていたので、かなりびびってます（（（゜Д゜；）））ガクガク。はてぶコメントでも多くのご指摘をいただきまして、私自身反省している点もあるので、少し補足しておこうかと思います。 昨日の記事の意図は、まず単純に不正な UTF-8 シーケンスの存在を知ってもらい、そして具体的な対策として、入力の水際で不正な UTF-8 シーケンスを潰してしまおうというものです。ここが説明の足りなかった部分ですが、入力段で HTML などのエスケープをしようということではありません。 UTF-8 の正規化は HTML などのそれと違って二重にかけても結果が変わりません。また、目的はクライアントの保
UTF-8 エンコーディングの危険性 - WebOS Goodies
基本的に、まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。実際、 Opera, Firefox, IE ともに適切にエスケープしてくれました。また、 UCS に変換した後にエスケープ処理を行うことでも対処できるかもしれません。しかし、複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。 例えば Ruby の場合、不正な UTF-8 コードを検出する最も簡単な方法は、 String#unpack を使って UCS へ変換してみることです（昨日の記事への kazutanaka さんからのはてぶコメントにて、 iconv でも同様なこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
