入力バリデーション

入力バリデーションとは

入力バリデーションは、ユーザー入力を検証し、不正なデータがシステムに入り込むのを防ぐセキュリティの基本である。想定する長さや範囲を超えた入力を入口で弾くバッファオーバーフロー対策のように、バリデーションが直接効く欠陥もある。

一方で、SQL インジェクションや XSS を「入力バリデーションの欠如が原因」と片付けるのは機序の取り違えである。どちらもデータをクエリ文字列や HTML へ埋め込む出口の処理で成立する欠陥で、第一の防御はそれぞれパラメータ化クエリ (プリペアードステートメント) と埋め込み先の文脈に応じた出力エスケープである。OWASP も入力バリデーションをこれらの攻撃を防ぐ主たる手段として使うべきではないとしており、バリデーションの役割は攻撃が成立する範囲を狭めて被害を小さくすることに置かれる。< やアポストロフィを含む入力を一律に拒否すれば、正当な文章が書けなくなるうえに根本の欠陥は残る。

バリデーションの原則

許可する値を定義する許可リスト (ホワイトリスト) 方式が推奨で、禁止する値を定義する拒否リスト (ブラックリスト) 方式は不十分だ。クライアントの検証は回避可能なため、必ずサーバーサイドで検証する。不正な入力は即座に拒否し、早期に失敗させる。

バリデーションの層

バリデーションの層を図で示す。

クライアント (UX 向上)
  ↓ フォームバリデーション (即座にフィードバック)
API Gateway (スキーマ検証)
  ↓ リクエストバリデーター
Lambda (ビジネスルール)
  ↓ Zod, Joi 等でバリデーション
DynamoDB (制約)
  ↓ 条件付き書き込み

よくあるバリデーション

よくあるバリデーションを以下にまとめる。

フィールド	バリデーション
メールアドレス	形式チェック、長さ制限
パスワード	最小長、複雑さ
数値	範囲チェック、整数チェック
文字列	長さ制限、許可文字
URL	形式チェック、プロトコル制限
ファイル	サイズ、MIME タイプ

このうちメールアドレスは扱いが難しい。構文は RFC 5321 で定義されており一般の想像よりはるかに複雑なため、厳密な正規表現を書こうとすると正当なアドレスを弾く方向に壊れる。@ の存在と長さの上限程度の簡易な検査に留め、そのアドレスが本人のものかは確認メールの到達で確かめるのが実務的である。

バリデーションのアンチパターン

バリデーションのアンチパターンを以下にまとめる。

アンチパターン	問題
クライアントのみで検証	サーバーに直接リクエスト可能
拒否リストのみ	新しい攻撃パターンを見逃す
エラーメッセージに詳細を含む	攻撃者に情報を与える
同じ規則を各所へ書き写す	仕様変更時に直し漏れが出て層ごとに判定が食い違う

入力バリデーションの背景や設計思想は関連書籍に詳しい。