@kyanny's blog

My life. Opinions are my own.

4. Webアプリケーションの機能別に見るセキュリティバグ (4.2 入力処理とセキュリティ)

Webアプリケーションの入力には、 HTTP リクエストとして渡されるパラメータ (GET、POST、クッキーなど) があります。

    • クッキーやヘッダなども入力である == 脆弱性がないか注意、意識を忘れずに
  • 文字エンコーディング
    • 文字エンコーディングに起因する脆弱性も存在する (UTF-7 とか)
  • 入力値検証
    • 入力値の間違いを早期に発見して再入力を促すことによりユーザービリティを向上させる
    • 間違った処理を継続してデータ不整合がおこるのを防ぎ、システムの信頼性を向上させる
  • バイナリセーフという考え方

バイナリセーフとは、入力値がどんなバイト列であっても正しく扱えることを意味しますが、典型的には値ゼロのバイト(ヌルバイト、 \0 と表記されることが多い)が現れても正しく処理できることを指します。

  • ヌルバイト攻撃
    • ヌルバイトがあらわれると文字列終端とみなされて「意図しない終端文字によるデータの終了と、想定外の処理の注入」がおこる
  • 制御文字のチェック (正規表現、ただし入力チェックだけではダメ)
    • 文字列への全体一致(文字列先頭、文字列末尾)は \A \z で (^, $ は改行文字を含む文字列の場合、期待した動作にならないことがある)

データの先頭は \A、データの末尾は \z で示します。 ^ と $ は「行の」先頭と末尾を示すものなので $ が改行にマッチすることから、 ^ と $ をデータの先頭・末尾として使うと不具合が生じる場合があります。

    • ^, $ でマッチさせたチェックに対し、 %0a (ラインフィード LF) を含んだ文字列をあたえてチェックをすり抜ける例
  • :cntrl: という POSIX 文字クラス
  • \d, \w が「全角英数」にマッチしてしまうケース
  • 「制御文字以外」を示す正規表現 \P{Cc}