前回は、文字コードの引き起こす問題がソフトウェアの処理上だけでなく、人間に対する視覚的な効果という点でも強く影響を与え、攻撃者にとっての強力な道具となることがある、という点について説明しました。今回も前回に引き続き、そのような文字コードが引き起こす視覚的な問題点について説明します。 拡張子の偽装 Unicodeを利用したWindowsにおける拡張子の偽装は、文字コードを利用した視覚的な攻撃の中でも特にインパクトの大きいものだと思います。 Unicodeには多数の文字に加え、さまざまな制御も収録されています。そのような制御コードのうち、U+202E「RIGHT-TO-LEFT OVERRIDE」（RLO）と呼ばれる文字をファイル名に含めることで、見かけ上の拡張子を簡単に偽装することができます。 たとえば、copy-txt.exeという名前の実行可能ファイルがあったとします。 図1 copy
Twitterで書いた方が良いようなエントリですが、たまには良いでしょう。 #perl – utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 という記事がありました。PHPにも似た関数、utf8_decodeがあります。PHPでも使ってはなりません。日本人というよりマルチバイト圏で使っている人はほとんどいないはずです。理由はコードを見れば一目瞭然です。 /* All the encoding functions are set to NULL right now, since all * the encoding is currently done internally by expat/xmltok. */ xml_encoding xml_encodings[] = { { "ISO-8859-1", xml_decode_iso_8859_
これまでに挙げた文字コードについて、正規表現を使用して mb_check_encoding() の代替用の関数を書いてみました。ある程度、妥当なものになっているとは思いますが、間違い等に気付いた方がおられましたら、ご指摘ください。 UTF-8 については、RFC3629 を参考にしました。各文字は4バイト以下、冗長な表現、サロゲートペアの領域を FALSE と判定します。 <?php function is_valid_encoding( $str, $encoding ) { switch ( $encoding ) { case 'ASCII' : $regex = '/(?:' . '[\x00-\x7f]' // ASCII (mb_check_encoding) // . '[\x00\x09\x0a\x0d\x20-\x7f]' // ASCII (mb_detect_enco
今回解説するWebアプリケーションのバリデーションの欠陥はPHPに限った問題ではありません。多くのプラットフォームのWebアプリケーションで見過ごされているバリデーション仕様の欠陥です。それは文字エンコーディングのチェックです。 文字エンコーディングバリデーションの必要性 筆者の知る限りでは、2004年に相次いで今まで知られていなかったアタックベクタ（攻撃経路）が見つかりました。2004年に多く見つかった新しいアタックベクタとは不正な文字エンコーディングを利用した攻撃です。不正な文字列を利用したJavaScriptインジェクションやSQLインジェクションの攻撃手法が公開されました。 文字エンコーディングを利用した攻撃自体は当時でも新しい攻撃手法ではありませんでした。文字エンコーディングを利用した攻撃は、少なくとも2000年から広く知られていた攻撃手法でした。ブラウザが文字エンコーディングを
「文字集合と文字エンコーディング」というタイトルで、経験2〜3年目の人をターゲットに社内勉強会を開催しました。文字集合という単語を知っている必要はないですけど、少なくともUTF-8とShift_JISとでは扱える文字の種類数が違うことだけは伝えたかったので、その意味では目標が達成できたと思っています。 まとめ 文字集合とは、扱える文字の集合 JIS X 0208なら6000文字くらいの日本語の文字 UCS-2なら60000文字くらいの世界中の主要な文字 文字エンコーディングとは、文字の集合をバイト列に直す方式 Shift_JISはJIS X 0208（など）を1〜2バイトにする UTF-8はUCS-2を1〜3バイトにする 文字エンコーディング関連のツールを使いこなそう nkfやlvを使いこなそう 日本語を探すならlgrep 最終兵器：hexjaで16進ダンプ ムービー
今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
