境界線の防衛学：ホワイトリストという「絶対的な聖域」をどう設計するか
セキュリティの世界で「ブラックリストは無能である」と断言するのは簡単だ。だが、なぜ無能なのか。それは攻撃者が常に「想定外のエンコーディング」という地下道を通って侵入してくるからだ。
SQLインジェクションやOSコマンドインジェクションを食い止めるために、「'（シングルクォート）を除去する」といったブラックリスト的発想に頼るエンジニアは、いまだに後を絶たない。しかし、攻撃者はUnicodeの正規化、マルチバイト文字の食い込み、あるいはWAFをすり抜けるためのプロトコルレベルのパケット断片化を使って、フィルタリングの網をすり抜けてくる。
本稿では、ホワイトリスト方式を単なる「入力チェック」ではなく、アプリケーションの境界線（Trust Boundary）を守るための強固なアーキテクチャとしてどう実装すべきか、その深淵を解説する。
—
1. ブラックリストの限界と「未知の攻撃」への敗北
ブラックリストの根本的な欠陥は、それが「既知の悪意」のリストに依存している点にある。攻撃者は常に新しい文字セットや、データベース固有の構文解析の癖（例：MySQLのコメントアウト記法や、PostgreSQLのキャスト演算子）を利用し、フィルターを無効化する。
例えば、SELECT FROM users WHERE name = 'input' というクエリに対し、input に %00（ヌルバイト）を注入したり、特定のロケール環境下でエスケープシーケンスを破壊したりする手法は、ブラックリストでは防ぎようがない。結局のところ、ブラックリストは「何が悪いか」を定義しているに過ぎず、「何が正常か」を定義していないからだ。
—
2. ホワイトリスト・バリデーションの実装論
真のホワイトリストとは、入力値を「許可される性質」で厳格に縛り上げることだ。ここでは、正規表現を用いたバリデーションを例に、堅牢な設計を示そう。
実装例：型定義と正規表現による制約
単なる文字列チェックではなく、ドメイン駆動設計（DDD）の文脈で「値オブジェクト」として扱うのがベストプラクティスだ。
import re
from dataclasses import dataclass
@dataclass(frozen=True)
class Username:
value: str
def __post_init__(self):
# 【重要】正規表現は「含んではいけないもの」ではなく「許可するもの」のみを定義する
# 英数字とアンダースコアのみ、かつ先頭は英字、長さは3-16文字
pattern = re.compile(r’^[a-zA-Z][a-zA-Z0-9_]{2,15}$’)
if not pattern.match(self.value):
# 不正な入力は即座に例外を投げ、処理を停止する（Fail-Fast）
raise ValueError(f”Invalid username format: {self.value}”)
実行時：不正な入力を弾く
try:
user = Username(“admin’; DROP TABLE users;–“)
except ValueError as e:
# ログには詳細を残し、ユーザーには汎用的なエラーを返す
print(f”セキュリティログ出力: 不正な入力が検出されました – {e}”)
この実装において重要なのは、re.match を使い、文字列の先頭（^）から末尾（$）までを完全にマッチさせている点だ。一部でも一致すればOKとする re.search を使ってしまうと、攻撃者は改行コードを挟んでSQL文を忍び込ませることが可能になる。
—
3. 生成AI時代の新たな脅威：プロンプトインジェクションへの応用
最近では、LLM（大規模言語モデル）を用いたアプリケーションにおけるプロンプトインジェクションが懸念されている。ここでもホワイトリストの概念は通用する。
ユーザー入力をそのままプロンプトのコンテキストに埋め込むのではなく、「期待される構造（JSONスキーマ等）へのマッピング」を強制するのだ。
- ガードレイルの実装: 入力値に対して、モデルが生成する前に「期待される入力フォーマット」に合致しているかを検証する中間層（Validator Layer）を設置する。
- 構造化出力の強制: LLMには自然言語ではなく、JSONスキーマを遵守した出力のみを許可し、それ以外の「指示を上書きするような自然言語」は、アプリケーション側でパースエラーとして破棄する。
—
4. チーフホワイトハッカーからの提言：アーキテクチャの監査点
システムを監査する際、私はコードの行数よりも「入力値がどこで正規化され、どこで検証されているか」のパスを追う。
1. 境界の定義: 外部からの入力は、アプリケーションの「入り口」で即座にデータ型（Username, Email, Amount等）に変換されているか？
2. 正規化の順序: URLデコード → 正規化（Unicode Normalization） → バリデーション の順序が守られているか？（先にバリデーションを行うと、その後のデコードで不正な文字が顕現する）
3. 防衛的プログラミング: ライブラリの更新を待つのではなく、自分たちのコードが「入力値の性質」を定義できているか。
ホワイトリストは、決して窮屈な制約ではない。それは、君たちのアプリケーションが「正常なデータ以外を拒絶する」という、最も強力な武器なのだ。
コードを書くとき、常に自問してほしい。「この入力値は、システムが期待する『正しい姿』を100%規定できているか？」と。その問いにYesと答えられるとき、君たちのシステムは攻撃者にとって最も攻略困難な難攻不落の要塞となる。
コメント