第3回: Unicode から ISO-8859-1 への変換
前回の予告では「ASCIIへの変換」と書いたのですが、英語版 Windows の標準の ANSIコードページ(コードページ1252)を対象に話を進めますので ASCII ではなく ISO-8859-1 です。
さて、ISO-8859-1 についても 前回、前々回と同様に WC_NO_BEST_FIT_CHARS を指定せずに WideCharToMultiByte を使って Unicode から変換させてみましょう。「似たような文字」として変換される文字の一覧を示しておきます。文字が多いのと、charset=ISO-8859-1 になっているということで、日記とはわけてあります。
「似たような文字」に変換される文字の数が、Shift_JIS(コードページ932)のときに比べ圧倒的に多くなりますので、これにより引き起こされるセキュリティ上の問題も Shift_JIS (コードページ932) に比べ増加します。このような変換によって引き起こされる脆弱性の代表的な例としては、以下のようなものが考えられます。
- ディレクトリトラバーサル
- '∖' (U+2216)、'＼' (U+FF3C) がコードページ1252への変換で 0x5C に変換されます。また、'⁄' (U+2044)、'∕' (U+2215)、'／' (U+FF0F) が '/' (0x3F) に変換されます。そのため、Unicode にて文字列の検証を行ったあとにコードページ1252へ変換される場合、変換後の文字列に 0x5C が混入し、ディレクトリトラバーサルが発生する可能性があります。
- XSS、SQLインジェクション
- Shift_JIS への変換と同様に、ŚČŔĬℙŤ (U+015A U+010C U+0154 U+012C U+2119 U+0164) や σℂℝℑ₧Ʈ (U+03C3 U+2102 U+211D U+2111 U+20A7 U+01AE) などの文字列は、全て "SCRIPT" に変換されます。また、アルファベットだけでなく '〈' (U+2329) や '〈' (U+3008)、'＜' (U+FF1C) は '<' (0x3C) に、' ʺ ' (U+02BA) や ' ̎ ' (U+030E)、' ＂ ' (U+FF02) は '"' (0x22) に変換されます。このように HTML や SQL のメタキャラクタに変換される文字も多数ありますので、Unicode にてこれらの文字を含む文字列の検証を行ったあとにコードページ1252へ変換された場合には、XSS やSQL インジェクションの原因となりえます。
- 予約デバイス名
- Shift_JISのときと同様に、Unicode のままでは問題のないファイル名が、コードページ1252に変換されることにより予約デバイス名となり、サービス不能を引き起こすことがあります。例えば、変換後の結果が 'A' (0x41) になるような Unicode の文字は、'Ā' (U+0100)、'Ă' (U+0102)、'Ą' (U+0104)、'Ǎ' (U+01CD)、'Ǟ' (U+01DE)、'Ａ' (U+FF21) の6文字となりますので、ĀUX や ĂUX、ǍUX といったファイル名は、コードページ1252に変換されると全て AUX という予約デバイス名となります。
このように、Unicode から変換した際に「似たような文字」に変換される文字はShift_JIS(コードページ932)のときに比べ圧倒的に多いこと、英語圏における Unicode の理解度が低いであろうことから、英語圏で作成されたアプリケーションを英語環境で動作させる場合に Unicode が引き起こす脆弱性というのは、潜在的には Shift_JIS の場合よりも多いのではないかと想像されます。
次回は Unicode 文字列の比較をテーマにしたいと思います。
