第9回 文字コードが引き起こす表示上の問題点［前編］ | gihyo.jp
文字コードが引き起こす問題点は、これまで説明したような比較の一致・不一致といったソフトウェアの処理上のものだけでなく、人間に対する視覚的な効果という点でも強く影響を与え、攻撃者にとっての強力な道具となることがあります。 今回および次回で、そのような文字コードが引き起こす視覚的な問題点を紹介します。 視覚的に似た文字 見かけのよく似た文字は、フィッシングなどによく利用されます。典型的な例としては、アルファベット小文字のl（エル）と数字の1などがあります。たとえば、http://bank1.example.jp/ というURLのオンラインバンクがあったとすると、攻撃者は http://bankl.example.jp/ というURLを使ってフィッシングを企むということは容易に想像できると思います。 もちろん、収録している文字数が増えれば増えるだけ、このように見かけのよく似た文字が存在する率も高
第27回 見過ごされているWebアプリケーションのバリデーションの欠陥 | gihyo.jp
今回解説するWebアプリケーションのバリデーションの欠陥はPHPに限った問題ではありません。多くのプラットフォームのWebアプリケーションで見過ごされているバリデーション仕様の欠陥です。それは文字エンコーディングのチェックです。 文字エンコーディングバリデーションの必要性 筆者の知る限りでは、2004年に相次いで今まで知られていなかったアタックベクタ（攻撃経路）が見つかりました。2004年に多く見つかった新しいアタックベクタとは不正な文字エンコーディングを利用した攻撃です。不正な文字列を利用したJavaScriptインジェクションやSQLインジェクションの攻撃手法が公開されました。 文字エンコーディングを利用した攻撃自体は当時でも新しい攻撃手法ではありませんでした。文字エンコーディングを利用した攻撃は、少なくとも2000年から広く知られていた攻撃手法でした。ブラウザが文字エンコーディングを
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
本当は怖い文字コードの話 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文字コードに起因する脆弱性とその対策
