Open2021/11/13にコメント追加1

ウェブ・セキュリティ基礎試験(徳丸基礎試験)⑩

徳丸基礎試験勉強まとめ⑩

「体系的に学ぶ安全なWebアプリケーションの作り方第2版」の6章を自分なりにまとめる
アドバイスや間違い指摘など歓迎です

6章「文字コードとセキュリティ」

文字集合
- 1byte系
  - US-ASCII(7 bit): English
  - ISO-8859-1(8 bit): English, Frenchなど
  - JIS X 0201(8 bit): English, カタカナ
- 2byte系
  - JIS X 0208(16 bit): 日本語
  - マイクロソフト標準(16 bit): 日本語
  - JIS X 0213(16 bit): 日本語
  - Unicode(21 bit): 世界共通
異なる文字が同じコードに割り当てられる問題
- 0x5CがASCIIだとバックスラッシュ、JIS X 0201だとエンマークなど
- なので、JIS X 0201で0x5Cがバックスラッシュのエスケープ処理をすり抜け、ASCIIに変換されてバックスラッシュとして復活するなどの問題がある

文字エンコーディング
- 先に普及した1byte文字と後続の2byte文字の互換性を保った文字符号化方式(2byte)
Shift-JIS
- 2byte文字の1byte目(先行byte)をJIS X 0201の空き領域にマッピング
- 効率よく文字を表現できるが、1byteを取り出した場合、1byte目かわからず、誤動作する場合がある
- 0x83, 0x89, 0x83, 0x8a,0x95, 0x5c(ラリ表)などの文字列で、0x89, 0x83(宴)や,0x5c(￥)を判定する関数を使うときなど。
- 対策
  - マルチバイト対応の関数を使用する、Shift-JISではなく、UTF-8を使用する
EUC-JP
- 1byte目: 0x20 ~ 0x80はUS-ASCII, 0xa0 ~ 0xffはJIS X 0208の先行バイト
- 2byte目: 0xa0 ~ 0xffはJIS X 0208の2byte目
- 各領域の重なりががないので、0x5c問題は発生しない
- 0xa5, 0xe9, 0xa5, 0xea(ラリ)の文字列で、1byteずれた0xe9, 0xa5(薀)を誤判定する問題は残る
- 対策
  - マルチバイト対応の関数を使用する、EUC-JPではなく、UTF-8を使用する
ISO-2022-JP
- エスケープシーケンスでUS-ASCIIとJIS X 0208を切り替える
UTF-16
- サロゲートペアでBMP以外の文字に対応(16bit)
UTF-8
- 1byte ~ 4byteの可変長
- 各領域の重なりががないので、0x5c問題は発生しない
- 非最短形式(/など、最短形式の場合0x2Fだが、2byte~4byteでも表現可能)文字の場合は、誤判定する問題がある

文字エンコーディングとして不正なバイト列による脆弱性
- 不正なバイト列が入った場合、そのバイト以降が無視されてしまい、エスケープ処理をすり抜けるなどの問題が起こる
文字エンコーディングの扱いの不備による脆弱性
- 0x5c問題など
文字集合の変更に起因する脆弱性
- JIS X 0201で0x5Cがバックスラッシュのエスケープ処理をすり抜け、ASCIIに変換されてバックスラッシュとして復活するなど

アプリケーション全体の文字集合統一する
不正な文字エンコーディングをエラーにする
文字エンコーディングを正しく扱う
- マルチバイト対応関数の使用、関数の引数として文字エンコーディング明示
出力時に文字エンコーディング指定する
- レスポンスヘッダのContent-Typeで文字エンコーディングを正しく指定
- DBの文字エンコーディングを正しく指定
  - 「尾骶骨」テストや、「𠮷（つちよし）」テストで確認
- その他文字エンコーディングを指定する場所はもれなく指定