境界線は「拒否」ではなく「許可」で引け：インジェクション攻撃を無力化するホワイトリスト思考
現場のエンジニア諸君、日々お疲れ様。今日もどこかのサーバーで、脆弱性を突こうとする無数のリクエストがログを埋め尽くしているはずだ。
よく「バリデーションは完璧にやっています」という言葉を聞くが、その「完璧」の定義は何だ？ 多くの現場で採用されているブラックリスト方式（NGワードの除外）は、実はセキュリティの観点から見ればザルも同然だ。攻撃者は常に我々の想定の斜め上、あるいは「エンコーディングの死角」を突いてくる。
今日は、インジェクション攻撃を根本から無力化する「ホワイトリスト方式」の哲学と、実務で明日から使える実装コードを叩き込む。
—
1. ブラックリスト方式が「敗北」する理由
例えば、SQLインジェクションを防ぐために「'（シングルクォート）を除去する」というロジックを組むとしよう。しかし、以下の事態を想像できるか？
- エンコーディング攻撃: URLエンコードや二重エンコード、あるいはUnicode正規化の隙を突かれる。
- コンテキストの不一致: SQLだけでなく、OSコマンド、LDAP、さらにはテンプレートエンジンへのインジェクションなど、攻撃手法は多岐にわたる。
- 未知のペイロード: 攻撃者は常に新しい「回避コード」を開発している。ブラックリストは「既知の悪」を追うだけであり、「未知の善」以外を排除する設計には勝てない。
だからこそ、我々は「許可するものだけを通す」ホワイトリスト方式を信奉する。これは単なる規約ではなく、戦術的な生存戦略だ。
—
2. 実践的実装：ホワイトリストによるバリデーション
「期待される型、範囲、形式」以外は門前払いにする。これが鉄則だ。
Python (FastAPI/Pydantic) での厳格な入力検証
現代的な開発では、型ヒントとバリデーションライブラリを組み合わせるのが最も堅牢だ。
from pydantic import BaseModel, Field, validator
import re
class UserProfileUpdate(BaseModel):
# ユーザーIDは数値のみ、正の整数に限定
user_id: int = Field(gt=0)
# ユーザー名は英数字かつ3-16文字のみを許可（正規表現によるホワイトリスト）
username: str = Field(…, min_length=3, max_length=16)
@validator(‘username’)
def username_must_be_alphanumeric(cls, v):
if not re.match(r’^[a-zA-Z0-9]+$’, v):
raise ValueError(‘ユーザー名は英数字のみ許可されています’)
return v
これをエンドポイントで受け取れば、不正な文字列は自動的に422エラーになる
JavaScript (Node.js) での入力フィルタリング
フロントエンドのバリデーションは「UXのため」だが、バックエンドのバリデーションは「生存のため」だ。
// ホワイトリストによるID検証の例
function validateUserId(input) {
// 期待値：数値のみ、かつ10桁以内
const idRegex = /^\d{1,10}$/;
if (typeof input !== ‘string’ || !idRegex.test(input)) {
throw new Error(“Invalid Input: IDは数字10桁以内で指定してください”);
}
return parseInt(input, 10);
}
—
3. インフラ層での「多層防御」：WAFとNginxの活用
アプリ側のコードを万が一すり抜けても、インフラ層で「あり得ないリクエスト」を捨てる。これが防御の要だ。
Nginxでのリクエスト制限（概念設定）
$arg_id など、クエリパラメータが予期せぬ形式なら即座に403を返す。
特定のIDパラメータが数字でない場合は弾く
if ($arg_id !~ ^[0-9]+$) {
return 403;
}
WAF（AWS WAF等）の設定指針
WAFの設定でも「特定の文字列をブロック」するのではなく、「特定のパターン（Regex Match Set）に一致しないものはすべてブロック」するルールを優先的に適用する。
- Positive Security Model: 許可されたリクエストのパターンを定義し、それ以外をすべて落とす。運用コストは高いが、これが最も攻撃に強い。
—
4. セキュリティチーフからの最後のアドバイス
「バリデーションは面倒だ」と思うかもしれない。しかし、インシデント対応で深夜に叩き起こされ、ログを追いかけ、謝罪会見の準備をするコストに比べれば、この実装なんて鼻歌混じりで終わる作業だ。
「入力値を信用しない」という疑心暗鬼こそが、最強のエンジニアの武器になる。
今日紹介したコードは、あくまで「最低限」のラインだ。これに加えて、DBへのクエリは必ずプリペアドステートメントを使用すること。バリデーションは「最後の砦」ではなく、「最初の一歩」であることを忘れないでほしい。
さあ、エディタを開いて、君たちのコードの「門」をより強固なものに書き換えよう。健闘を祈る。
コメント