「ブラックリストは死んだ」：インジェクション防御の境界線と、型安全なアーキテクチャへの回帰
セキュリティ・カンファレンスの廊下で若手エンジニアから「このバリデーション、正規表現で危険な文字を除外しているから大丈夫ですよね？」と聞かれるたび、私は溜息を隠すのに苦労する。
結論から言おう。ブラックリスト方式による入力値検証は、もはや防御ではなく「気休め」だ。攻撃者は常に我々の想像の斜め上を行くエンコーディングを駆使し、WAFやアプリケーションのフィルタリングをすり抜ける。SQLインジェクション（SQLi）の歴史を見れば明らかだが、' OR 1=1 -- を弾いたところで、マルチバイト文字の食い込みや、データベース固有の構文解析の不備を突くペイロードの前では無力だ。
我々が目指すべきは、「悪意のあるものを捨てる」ことではなく、「期待されるもの以外を一切通さない」という冷徹なホワイトリスト・アーキテクチャである。
—
1. バリデーションの本質：推論ではなく「型」への強制
インジェクション攻撃の根本原因は、「データ」と「制御構文（コード）」の境界が曖昧になることにある。プロトコル解析やメモリダンプを追っていると分かるが、攻撃者は必ずアプリケーションが想定する「型の制約」を逸脱する値を送り込んでくる。
ここで言うホワイトリストとは、単なる文字列一致ではない。入力値がアプリケーションのビジネスロジックに到達する前に、「期待されるドメインモデルの型」へ強制変換（キャスト）することを指す。
実装例：TypeScript/Zodを用いた厳格なバリデーション
リクエストボディをそのままオブジェクトとして扱うのではなく、型定義（スキーマ）を通過させない限り、一切のロジックに触れさせない設計だ。
import { z } from ‘zod’;
// 外部からの入力値には「一切の信頼」を置かない
// 許容範囲を厳格に定義したホワイトリスト
const UserInputSchema = z.object({
userId: z.string().uuid(), // UUIDフォーマット以外は即座に拒絶
action: z.enum([‘read’, ‘write’, ‘delete’]), // 列挙型以外の入力を許さない
limit: z.number().int().min(1).max(100), // 数値の範囲を物理的に制限
});
function handleRequest(rawInput: unknown) {
// ここでバリデーションを通過しない場合は例外を投げる
const data = UserInputSchema.parse(rawInput);
// 以降のロジックでは、dataは型安全が保証されている
executeDatabaseQuery(data.userId, data.limit);
}
このアプローチの利点は、後続のコードでエスケープ処理を忘れても、すでにデータ型が保証されているため、インジェクションの余地が物理的に存在しない点にある。
—
2. 生成AI時代のガードレイル：プロンプトインジェクションへの応用
現在、我々の最大の懸念は、LLM（大規模言語モデル）に対するプロンプトインジェクションだ。これは従来のSQLi以上に厄介だ。なぜなら、LLMは「自然言語」という非構造化データを処理するからだ。
ここでもホワイトリストの思想は生きる。LLMのコンテキストに渡す入力値に対し、「構造的ガードレイル」を敷くのだ。例えば、ユーザー入力をそのままLLMのシステムプロンプトに結合してはならない。
- 構造化データへの変換: ユーザーの入力は一度JSON形式のバリデーションを通し、パラメータのみを抽出する。
- セマンティック・フィルター: 入力値が「命令」の性質を帯びていないか、ベクトルデータベースを用いて既存の悪意あるパターン（jailbreakパターン）と類似度判定を行う。
—
3. 低レイヤから見た「境界」の重要性
ネットワークパケットの構造や、OSコマンドインジェクションの挙動を深く掘り下げると、防御の要諦は「インターフェースの最小化」に集約される。
システムコールを直接呼ぶようなモジュールや、外部プロセスを起動する機能は、可能な限りホワイトリスト化されたパス（フルパス指定）と、認可された引数のみを受け取るラッパー関数の中にカプセル化すべきだ。
import subprocess
import os
悪例: ユーザー入力をそのままシェルに渡す（論外）
subprocess.call(f”ls {user_input}”, shell=True)
改善案: ホワイトリストによるコマンド制御
def safe_execute_command(user_input: str):
ALLOWED_COMMANDS = {“list”: “/usr/bin/ls”, “status”: “/usr/bin/ps”}
if user_input not in ALLOWED_COMMANDS:
raise ValueError(“無効なコマンドです”)
# 引数をリストで渡し、シェルを介さない（シェルのメタ文字展開を防ぐ）
subprocess.run([ALLOWED_COMMANDS[user_input], “-l”], check=True)
—
結論：プロフェッショナルとしての「疑心暗鬼」をコードに
最高峰のセキュリティとは、決して完璧な防御壁を築くことではない。「システムは常に侵害される可能性がある」という前提に立ち、侵害の影響範囲を型レベルで極小化し続けることである。
「ブラックリスト」は増え続ける攻撃手法を追いかける敗者のゲームだ。一方で「ホワイトリスト」は、アプリケーションの仕様を定義する我々（エンジニア）が、フィールドを支配するための最強の武器だ。
明日、あなたのコードベースを確認してほしい。バリデーションロジックの中に if (input.includes(';')) や regex.test(/--/) といった記述がないか。もしあれば、それは即座に削除し、「このフィールドには、この型とこの値しか存在してはならない」という仕様への書き換えを開始すべきだ。
セキュリティとは、技術力以上に、エンジニアの意志の強さの問題である。妥協のないアーキテクチャだけが、我々のインフラを、そしてユーザーを救うことができる。
コメント