ダウンロード - PHPカンファレンス2010 テックデイ 講演資料phpconf2010.pdf(792KB) アジェンダ 文字コード超入門 文字コードの扱いに起因する脆弱性デモ6連発 文字コードの扱いに関する原則 現実的な設計・開発指針 まとめ
Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
Rails 2系のXSS脆弱性がRuby 1.9では影響なしとされる理由 - 岩本隆史の日記帳（アーカイブ）
Rails 2系のXSS脆弱性を修正するパッチが先日公開されました。 4日(米国時間)、Ruby on Railsの2系すべてのバージョンにXSSの脆弱性があることがRiding Rails: XSS Vulnerability in Ruby on Railsにおいて発表された。特定のUnicode文字列を使ってチェックをくぐり抜け、任意のHTMLを送り込まれる危険性がある。なおRuby 1.9系で動作しているアプリケーションはこの影響を受けない。 http://journal.mycom.co.jp/news/2009/09/07/048/index.html この件に関して、大垣さんは次のように説明しています。 RoRの脆弱性に関連してRuby1.9では安全、と解説されていますが、それはRuby1.9は不正な文字エンコーディングを受け付けないからです。 何故かあたり前にならない文字エ
論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)
_文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不
Encode::decode_utf8()であってもis_utf8()を使うべき理由 - このブログはURLが変更になりました
404 Blog Not Found:#perl - utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 Validationの観点だけではなく、簡潔性の観点からも、Encode::decode_utf8()はおすすめです。すでに UTF-8 flag がついた文字列はそのままコピーするだけなので、条件分岐も不要です。 これは厳密にはこうなる。 Validationの観点だけではなく、簡潔性の観点からも、Encode::decode_utf8()はおすすめです。すでに UTF-8 flag がついた文字列はEncode-2.13以降であればそのままコピーするだけなので、条件分岐も不要です。 Encode-2.12ではそのままコピーしてない。そのままコピーするのは2.13以降での実装。 --- Encode-2.12/Encode.pm 2005-0
何故かあたり前にならない文字エンコーディングバリデーション - ikepyonのだめ人間日記
http://blog.ohgaki.net/char_encoding_must_be_validated まあ、当たり前にはならないでしょう。どう考えても不正な文字エンコーディングを受け付ける言語やらフレームワーク、DB、ブラウザが悪いと思う。不正な文字エンコーディングをチェックするというのはバッドノウハウだと思うし。そんなことに対応するのは大変すぎるからねぇ。 アプリ開発者を啓蒙するより、PHPとか直したほうが早いと思うんだけど。 XSSやSQLインジェクションが発生しないようにエスケープ処理やバインド機能を使うというのは、プログラムの基本に立ち返って、どんなデータが渡されても正確に処理を実行するために必要なことなので、当たり前といえると思う。 でも、不正な文字エンコーディングのチェックはプログラミング手法ではなく、それを受け取って変に解釈してしまうDBやらブラウザなどが直せないから
perl - EncodeでXSSを防ぐ : 404 Blog Not Found
2009年03月03日19:00 カテゴリLightweight Languages perl - EncodeでXSSを防ぐ 良記事。 第7回■文字エンコーディングが生み出すぜい弱性を知る：ITpro だけど、問題点のみ具体例があって、対策にないのが片手落ちに感じられたので、その点を補足。 結論だけ言ってしまえば、Perlなら以下の原則を守るだけです。 404 Blog Not Found:perl - Encode 入門 すでにOSCONでもYAPCでも、あちこちそちこちでこの基本方針に関しては話したのですが、ここ 404 Blog Not Found でも改めて。 Perl で utf8 化けしたときにどうしたらいいか - TokuLog 改め だまってコードを書けよハゲ入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これが
第6回 先行バイトの埋め込み | gihyo.jp
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
第5回 不正なバイト列の埋め込み | gihyo.jp
今回は、「不正なバイト列の埋め込み」という攻撃方法について紹介します。 文字列を入力とするソフトウェアにはさまざまなものがありますが、それらの処理系によっては、入力として与えた文字列中に、その文字コード上は不正となるようなバイト列を埋め込んでいたときに、それらのバイト列が無視されたり、想定外の文字に変換されてしまうことがあります。 たとえば、とあるソフトウェアにて （1) 処理A ＝ 文字列中に特定の文字（あるいは文字列）が含まれていないか検査 （2) 処理B ＝ 処理Aから受け取ったデータを処理。その際に不正なバイト列が無視あるいは別の文字に変換される という流れになっていた場合、後続の処理にて本来はフィルタリングされるべき文字列が含まれてしまうことになります。 このような流れを引き起こす具体的な例をいくつか紹介します。 Mozilla Firefoxにおける0x80の無視 Mozil
第4回 UTF-8の冗長なエンコード | gihyo.jp
今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1～4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U＋0000からU＋007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C（\）、0x2F（/）などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン
第9回■上流工程で文字集合仕様と文字エンコーディングを決定する
これらの対策のうち，ここでは「文字集合の変換を伴う変換をしない」など，アプリケーション全体の文字コードの取り扱いについて上流工程で留意すべき内容について説明しよう。「入力値のチェック」については次回以降，「入力値の検証」の項で詳しく説明する。「アプリケーションでの正しいマルチバイト文字の処理」については，個別の処理内容の項で説明する。 文字コードの取り扱いについて，上流工程で留意すべき点としては，次の三つが挙げられる。 要求仕様として文字集合を定義する端末がサポートする文字集合を確認する実装に用いる文字エンコーディングを決定する まずアプリケーション仕様として，処理対象となる文字集合を規定する必要がある。日英語以外の韓国語や中国語，アラビア語などの対応が必要な場合はUnicodeを選択するしかない。さらに日本語だけの場合でも，例えばJIS X 0201＋JIS X 0208はJIS第2水準
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
第8回■主要言語の文字エンコーディングの対応状況を押さえる
文字コードの問題に正しく対応する前提として，アプリケーションが稼働する基盤ソフトウエアがマルチバイト文字列処理に対応している必要がある。特に問題となるのが，言語処理系とデータベース管理システム（DBMS）である。利用者の使い方が正しくない場合も，ぜい弱性が混入することがある。このため，今回は主要言語とデータベース（MySQLとMS SQL Server）のマルチバイト文字対応状況について説明する。 文字列の処理単位は文字単位かバイト単位か Webアプリケーション開発で人気のあるスクリプト言語の多くは，かつては文字列をバイト単位で扱っているものが多かった。以下のPerlスクリプトは“漢字”という文字列の長さを表示するものだが，ソースの文字エンコーディングによって結果が変わる。具体的には，Shift_JISやEUC-JPの場合は4，UTF-8の場合は6と表示される。原因は，このスクリプトが文字
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
UTF-8 エンコーディングの危険性の補足 - WebOS Goodies
えー、昨日投稿した「UTF-8 エンコーディングの危険性」の記事ですが、なにを間違ったのか過去最高のアクセスを記録しています。その前の Ruby 用 JSON クラスの反響がさほどでもなく、今回も大したことないだろうと思っていたので、かなりびびってます（（（゜Д゜；）））ガクガク。はてぶコメントでも多くのご指摘をいただきまして、私自身反省している点もあるので、少し補足しておこうかと思います。 昨日の記事の意図は、まず単純に不正な UTF-8 シーケンスの存在を知ってもらい、そして具体的な対策として、入力の水際で不正な UTF-8 シーケンスを潰してしまおうというものです。ここが説明の足りなかった部分ですが、入力段で HTML などのエスケープをしようということではありません。 UTF-8 の正規化は HTML などのそれと違って二重にかけても結果が変わりません。また、目的はクライアントの保
yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須
(Last Updated On: 2016年3月3日)最近PostgreSQL、MySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考：セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQL、MySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト～6バイト必要なのか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文字コードに起因する脆弱性とその対策