文字コードの脆弱性はこの3年間でどの程度対策されたか?
4. デモ1:半端な先行バイトによるXSS • 半端な先行バイトとは – Shift_JIS、EUC-JP、UTF-8などマルチバイト文字の1 バイト目だけが独立して存在する状態 – 次の文字が、マルチバイト文字の2バイト目以降の文 字として「食われる」状況になる – input要素などの引用符「”」を食わせて、イベントハ ンドラを注入する攻撃 Copyright © 2010-2014 HASH Consulting Corp. 4 5. デモ１：PHPソース <?php session_start(); header('Content-Type: text/html; charset=Shift_JIS'); $p1 = @$_GET['p1']; $p2 = @$_GET['p2']; ?> <body> <form> PHP Version:<?php echo htmlspeci
円記号問題とウェブブラウザ - はてなるせだいあり
起源 円記号問題の始まりは1960年代にまで遡ります。1967 年に文字コード最初の国際規格である ISO R 646 が制定されましたが、その規格では 0x5C をはじめとして一部の文字が置き換え可能になっていました。アメリカの制定した ASCII では 0x5C に対して REVERSE SOLIDUS を割り当てました。一方、日本版である JIS X 0201 では YEN SIGN を割り当てました。 問題の拡大 7bit では扱いきれない文字を扱うため、世界で ISO 646 系のコードを拡張した文字コードが生まれました。日本ではシフトJIS、日本語 EUC、いわゆる JIS コードの三種類の文字コードが現れ、それぞれに多くの亜種が生まれました。では、それぞれの文字コードの 7bit 領域は ASCII と JIS X 0201 のどちらだったのでしょうか。 日本語 EUC 日本
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
第6回 先行バイトの埋め込み | gihyo.jp
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
文字コード polyglot - 葉っぱ日記
IE限定。外から指定されるcharsetに応じて挙動を変えるJavaScriptの関数の実装例。以下のコードを Shift_JIS として例えば charset.js のような名前で保存する。 function detectCharSet() { try{ var ADE = 'ｱｱ'; // 0xB1 x2 if(+ADE-0 == 10 ){ return 'UTF-7'; } if( ADE == 11 ){ return 'US-ASCII'; // 0xB1 means 0x31 } if( ADE.charCodeAt(0) == 0xFF71 ){ return 'Shift_JIS'; // Halfwidth Katakana Letter A x2 } if( ADE.charCodeAt(0) == 0x81FC ){ return 'EUC-JP'; // 0xB1
第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でのビットパターン
講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ
「文字集合と文字エンコーディング」というタイトルで、経験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進ダンプ ムービー
第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］ | gihyo.jp
前回に引き続き、UTF-7によるクロスサイトスクリプティング（XSS）について説明していきます。 UTF-7によるXSSは、攻撃対象のコンテンツの文字エンコーディングが不明瞭な場合に、そのコンテンツを被害者のブラウザ（Internet Explorer）で開いたときに、そのコンテンツの文字エンコーディングがUTF-7であるとIEに誤認させ、「+ADw-script+AD4-」のようなUTF-7の文字列が有効なHTML要素として認識されるために発生します。 そして、「文字エンコーディングが不明瞭」な具体的な状況として、以下のような条件のいずれかに該当するということを前回説明しました。 レスポンスヘッダ、meta要素のどちらでもcharsetが指定されていない charsetにIEが解釈できないエンコーディング名が指定されている meta要素でcharsetを指定しているときに、meta要
Exploiting Unicode-enabled software
Black Hat USA July 2009 Chris Weber www.lookout.net chris@casabasecurity.com Casaba Security Unraveling Unicode: A Bag of Tricks for Bug Hunting Black Hat USA - July 2009 © 2009 Chris Weber • Visual spoofing and counterfeiting • Text transformation attacks www.casabasecurity.com What’s this about? Black Hat USA - July 2009 © 2009 Chris Weber • Why you should care about Visual Integrity… – Branding
JavaのUTF-8におけるデコード処理の脆弱性を検証してみた。 - kensir0uのしくみ
情報源はこちら。 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5351 http://sunsolve.sun.com/search/document.do?assetkey=1-66-245246-1 http://www.unicode.org/versions/corrigendum1.html 問題は、Unicodeに準拠していないバイト配列でも中途半端に処理しているのが原因みたい。 対象はJRE6 update 10 以前のバージョン 検証したのは異なるバイト配列をUTF-8デコードした結果が同じ値となってしまうケース。 Sample Aが正常ケースでSample Bは異常ケースなんだけども、結果が同じとなった。 まぁJREを最新に更新すれば問題は解消されるみたい。 public class UTF8 { publ
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
制御文字をどうするのか | 水無月ばけらのえび日記
公開: 2009年3月11日0時12分頃 正規表現で「制御文字以外」のチェック (d.hatena.ne.jp) 個人的には、RLO(U+202E)みたいなUnicode系の制御文字をどう扱うべきなのかで悩みますね。入れられると困る気もするし、入れられないと困るような気もするし……。結局入れられるようにしてしまう事が多いのですが、RLOを入れられると表示が乱れたりする事があるわけで。 「制御文字をどうするのか」にコメントを書く関連する話題: Web
文字コードのセキュリティ問題はどう対策すべきか: 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に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
絵文字が開いてしまった「パンドラの箱」第1回--日本の携帯電話キャリアが選んだ道
Unicodeが携帯電話の絵文字を収録へ 絵文字ってなに？そう聞かれても多くの人は、ああ、それはと答えられるはず。そう言えばちょっと前に『メールのハートマークにだまされるな！ 8割の女性は「恋人以外にも使う」』（RBB NAVI）なんていうニュースもありました。携帯電話の個人普及率が9割を上回る（平成20年内閣府消費動向調査）この国において、絵文字はごくありふれたものになっている現実があります。 2008年の11月27日、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクト進行中であることを発表しました。では、このニュースは何を意味するのでしょう。そして私たちに何をもたらすのでしょう。今回から3回に分けて考えてみようと思います。 まず歴史を振り返ってみましょう。じつは絵文字を使ったのは携帯電話が最初というわけでありません。先行するもの
第6回■異なる文字集合への変換がぜい弱性につながる
文字集合自体は抽象的な「文字の集まり」に過ぎないので単独で問題になることはないが，異なる文字集合に変換する際には問題が発生する場合がある。文字集合が異なるということは，対応する文字が1対1対応していないので，変換先の文字集合で対応する文字がないケースや，多対1の対応が発生する可能性がある。 図1に，Unicodeからマイクロソフト標準キャラクタセットに変換する場合を例示した。マイクロソフト標準キャラクタセットには「骶」（尾てい骨の“てい”）や，ハングルなどはない。また，バックスラッシュ「\」（U+005C）と円記号「\」（U+00A5）がともにJIS X 0201の「\」（0x5C）に変換される場合について示している。 「漢」のように1対1対応している文字は問題ない。ハングルや「骶」のように対応するコードポイントがない場合はエラーになるか文字化けする。インターネットで「尾 骨 びていこつ」
スーパードライのダブルクオート - しろもじメモランダム
普通のシングルクオートは ‘ ’、ダブルクオートは “ ” であり、「6」「9」のような形でデザインされていることが多い*1。しかし、アサヒスーパードライのロゴにあるダブルクオートは、ちょっと違う。 開きのダブルクオートが、「6」ではなく「左右反転した9」になっている。なぜこういうデザインにしたのだろうか。横のラインを揃えるため？ wikipedia:en:Quotation mark glyphs を見てみると、Unicode にはこの「左右反転した9」タイプのクオーテーションマークも入っているらしい。このように記述がある*2。 Variants of ‘ and “ are: ‛ – U+201B (HTML: ‛) single high-reversed-9, or single reversed comma, quotation mark (This is somet
第5回■注目される文字コードのセキュリティ問題
今回から5回にわたって，アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか，疑問に思うかもしれないが，Webアプリケーションで文字コードを指定可能な個所は非常に多く，しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている（図1）。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では，ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して，文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは，セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう
複数の事象を混同しがちなVistaの文字問題
既にいくつかの記事で報道されているように，Windows Vistaでは，JIS X 0213:2004（JIS2004）と呼ぶ規格に対応し，利用できる文字数が増えるとともに一部の文字の形が変わる。そのことで，Windows Vistaを使うと文字に関して何か問題を起こすかのように思われている節があるようだ。 私が書いた記事でも，「これらの文字を使ってWindows Vistaで作った文書を，JIS2004に対応していない既存のWindowsで開くと，『・』や『■』などで表示される恐れがある」と記述しており，読者に対して余計な不安を与えてしまったかもしれない。また，「追加文字を使った文書を保存するときは，エンコーディングをUnicodeにする必要がある」との記述は，Windows Vistaだけのことかと誤解を与えてしまったかもしれない。これは，後で説明するようにWindows 98/NT
a threadless kite - 糸の切れた凧
ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
