普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
はじめに 与えられた文字列を含む文書を返す検索機能を実装しているところを想像してください。 検索語として「ページ」が与えられれば、「ページ」という文字列を含む文書を返します。これは特に難しいことではありません。 半角の「ﾍﾟｰｼﾞ」が与えられたらどうでしょう。「ページ」と「ﾍﾟｰｼﾞ」を区別する必要がないような、一般的な文書検索においては、「ページ」という文字列を含む文書を返すのが望ましいはずです（もちろん、この2つは常に同一視できるわけではありません。同一視できない例として本稿があります）。 もしかしたら、「㌻」で検索しようとする人がいるかもしれませんし、日本語を母国語としない人が、「へﾟ」（「ヘ」と半角の半濁点「ﾟ」）や「ﾍ゜」（半角カナ「ﾍ」と半濁点「゜」）を使うかもしれません。 人間なら簡単に対応できることですが、コンピュータで対応するには特別な処理が必要になります。例えばUnic
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
