文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。

ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです⁠）⁠、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。

この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。

具体的な例として、Windows上でのUnicodeからの変換について説明します。

Windows上でのUnicodeからShift_JISへの変換

Windows上での文字列のUnicode（UTF-16LE）からShift_JISへの変換においては、多くの場合APIのWideCharToMultiByteが使用されます。

このWideChatToMultiByte関数は、2番目の引数にWC_NO_BEST_FIT_CHARSというフラグを指定することができます。

WC_NO_BEST_FIT_CHARSを指定した場合、Unicode文字に対応するShift_JISの文字が存在しない場合には、特定の文字(デフォルトでは '?')に変換されます。

WC_NO_BEST_FIT_CHARSが指定されていない場合、Unicode文字に対応するShift_JISの文字が存在しない場合には、「よく似た文字」に変換されてしまいます。

WC_NO_BEST_FIT_CHARSを指定せずにWideCharToMultiByte関数を実際に呼び出した場合の文字の変換例を、表1に示しておきます。

この表を見るとわかるように、例えば発音記号のついた文字「À」（⁠U+00C0）やU+00C1（Á）はShift_JISに変換すると「A」（⁠0x41）に置き換わりますし、コピーライトマーク「©」（⁠U+00A9）は 「⁠c」（⁠0x63）に置き換わります。

このように、WC_NO_BEST_FIT_CHARS を設定しない変換においては、Unicode と Shift_JIS の間では多対一の変換が行われてしまいます。

Windows上でのUnicodeからISO-8859-1への変換

ISO-8859-1（Windows-1252）は、英語環境などで使われているエンコーディングです。これも実際にWC_NO_BEST_FIT_CHARSを指定せずにWideCharToMultiByte関数を使ってUnicodeからISO-8859-1へ変換した結果を表2に示しておきます。

UnicodeからISO-8859-1への変換の場合には、Shift_JISのときより非常に多くの文字が多対一で変換されていることが見て取れます。

たとえば、全角文字「Ａ」（⁠U+FF21）は0x41（A）に、添え字用の数字である「₀」（⁠U+2080）は「0」（⁠0x30）に変換されています。

問題を引き起こす「似た文字への変換」

このような多対一での文字の変換によって引き起こされるセキュリティ上の問題の一例としては、以下のようなものが考えられます。

パストラバーサル

UnicodeからShift_JISへの変換では、U+00A5の円記号「¥」が0x5Cのバックスラッシュ「\」に変換されます（日本語環境では表示する字体として円記号が当てられていますが⁠）⁠。

また、UnicodeからISO-8859-1への変換では、U+2216「∖」とU+FF3Cの全角のバックスラッシュ「＼」が ともに0x5Cのバックスラッシュ「\」に、U+2044「⁄⁠」⁠、U+2215「∕⁠」⁠、U+FF0F「／」が0x2Fのスラッシュ「/」に変換されます。

0x5Cや0x2FはWindowsにおけるディレクトリの区切りとして使用する文字ですので、Unicodeにて文字列の検証を行ったあとにShift_JISやISO-8859-1へ変換される場合、変換後の文字列に0x5Cが混入し、パストラバーサルが発生する可能性があります。

クロスサイトスクリプティング

UnicodeからISO-8859-1への変換では、U+2329「〈⁠」⁠、U+3008「〈⁠」⁠、U+FF1C「＜」といった文字が0x3C「に、また、U+02BA「ʺ⁠」⁠、U+030E「̎⁠」⁠、U+FF02「＂」が0x22「"」に変換されます。

前述のパストラバーサル同様、Unicode にて文字列の検証を行ったあとにShift_JISやISO-8859-1へ変換される場合、変換後の文字列に0x3Cや0x22といったメタキャラクタが含まれることになりますので、クロスサイトスクリプティングを引き起こす可能性があります。

このように、

1. Unicodeで文字列の検査を行う
2. Unicodeから他のエンコーディングに変換
3. 変換された文字列を使用する

といった順序のときに、本来であれば1.でフィルタリングされるべき文字が含まれてしまい、セキュリティ上の問題点を引き起こすというのが「多対一の変換」による攻撃の一般的なシナリオとなります。

次回は、この多対一の変換が引き起こしたソフトウェアの脆弱性の具体例を挙げながら、対策方法などについても説明したいと思います。