タグ

Securityとcharsetに関するyogoのブックマーク (5)

  • 第1回 UTF-7によるクロスサイトスクリプティング攻撃[前編] | gihyo.jp

    みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「⁠危険な文字列の検出」「⁠安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか(このルールを符号化方式あるいは文字エンコーディングと言います)に注意しなければならないこともあるでしょう。攻撃者は巧みに文字

    第1回 UTF-7によるクロスサイトスクリプティング攻撃[前編] | gihyo.jp
  • 文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)

    _U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、

  • 第7回■文字エンコーディングが生み出すぜい弱性を知る

    文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。(1)文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と,(2)文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング(1)――冗長なUTF-8符号化問題 まず,(1)の不正な文字エンコーディングの代表として,冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン(表1に再掲)を見ると,コード・ポイントの範囲ごとにビット・パターンが割り当てられているが,ビット・パターン上は,より多くのバイト数を使っても同じコー

    第7回■文字エンコーディングが生み出すぜい弱性を知る
  • 第5回■注目される文字コードのセキュリティ問題

    今回から5回にわたって,アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか,疑問に思うかもしれないが,Webアプリケーションで文字コードを指定可能な個所は非常に多く,しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている(図1)。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では,ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して,文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは,セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう

    第5回■注目される文字コードのセキュリティ問題
  • UTF-8 エンコーディングの危険性 - WebOS Goodies

    的に、まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。実際、 Opera, Firefox, IE ともに適切にエスケープしてくれました。また、 UCS に変換した後にエスケープ処理を行うことでも対処できるかもしれません。しかし、複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。 例えば Ruby の場合、不正な UTF-8 コードを検出する最も簡単な方法は、 String#unpack を使って UCS へ変換してみることです(昨日の記事への kazutanaka さんからのはてぶコメントにて、 iconv でも同様なこ

  • 1