境界線を型で制する：HackのTaint AnalysisでSQLインジェクションを撲滅する
HHVMの深淵を覗く諸君、コードレビューで「この変数はサニタイズしたか？」と繰り返す日々に別れを告げる準備はできているか。
Hackにおける「Strict Mode」は単なるシンタックスの強制ではない。それは、コンパイル時にプログラムの挙動を証明するための数学的基盤だ。今回は、その最上位機能の一つであるTaint Analysis（汚染解析）に焦点を当てる。
なぜ、まだ実行時にSQLインジェクションを恐れているのか？ 型システムに「何が危険で、何が安全か」を教え込めば、バグはコードが書かれた瞬間に検知されるべきだ。
—
1. Taint Analysisの核心：データフローの可視化
HHVMの静的解析エンジンは、単なる型の適合性だけでなく、データの「性質（Taint）」を追跡するグラフを内部で構築する。
- Source（ソース）: ユーザー入力（`$_GET`, `$_POST`など）から流入する「汚染された」データ。
- Sink（シンク）: データベースクエリやHTML出力など、悪意あるデータが到達してはならない「危険な出口」。
- Sanitizer（サニタイザー）: 汚染を解除する関数。
我々がやるべきことは、このパイプラインを型システムで厳格に規定することだ。
—
2. 実装：`@tainted` アノテーションによる防壁の構築
Hackでは、特定の型に `<<__Tainted>>` 属性や適切なエイリアスを付与することで、データフローを制御できる。しかし、実務において最も美しいのは、「信頼された型（Trusted Types）」を定義し、それを強制する設計パターンだ。
以下に、SQLインジェクションを理論的に不可能にする設計例を示す。
namespace App\Security;
// 信頼されたSQL断片のみを受け入れるための型ブランド
newtype SafeSql = string;
/
- 汚染された文字列から安全なSQLへ昇格させる唯一の門番。
- ここでのみ、エスケープやバリデーションを行う。
/
function to_safe_sql(string $input): SafeSql {
// 実際にはライブラリ側のエスケープ関数や、
// プリペアドステートメント用のパラメータバインディングを利用する
$sanitized = \mysql_real_escape_string($input);
return $sanitized;
}
/
- クエリ実行エンジン。
- 引数に SafeSql 型を要求することで、未加工の文字列を一切受け付けない。
/
function execute_query(SafeSql $query): void {
\db_execute($query);
}
// — 利用側 —
function handle_request(string $user_input): void {
// execute_query($user_input); // <- これを書くと型エラーでコンパイルが通らない！
$safe = to_safe_sql($user_input);
execute_query($safe); // OK
}
---
3. なぜこれが最強なのか：静的解析の「重み」
この設計の強みは、開発者が「サニタイズを忘れる」というヒューマンエラーを、HHVMの型チェッカーがビルド時に遮断してくれる点にある。
1. 境界の明確化: `SafeSql` は `string` とは別の型として扱われる。`string` を期待する場所には `SafeSql` は渡せるが、逆は不可能だ。
2. パフォーマンス: 実行時のオーバーヘッドはほぼゼロだ。`newtype`（opaque type）は、コンパイル時には型として厳格に管理されるが、ランタイム（HHVMのJIT）では単なる `string` として最適化される。これがHackのアーキテクチャの真骨頂だ。
3. 強制力: 新しい開発者がチームに加わっても、APIのシグネチャを `SafeSql` にしておけば、彼らが誤って危険なデータを渡すことは物理的に不可能になる。
—
4. チーフアーキテクトからの助言：実務への適用
プロダクションコードでこの手法を導入する際、以下の3点に注意せよ。
- Sinkを絞れ: 全ての関数を `SafeSql` で囲う必要はない。データベース接続のラッパーや、テンプレートエンジンの出力関数など、「最終的な出口」だけを型でロックせよ。
- 既存コードとの共存: 既存の膨大なコードベースに対しては、`HH_FIXME` を乱用するのではなく、`newtype` を段階的に導入し、境界線から少しずつ「型による防壁」を広げていく戦略を取れ。
- 信頼の連鎖を疑え: `to_safe_sql` の内部ロジックこそが、システムの最大のセキュリティホールだ。ここだけは極限までテストコードを書き、HHVMのプロファイラーで実行経路を可視化しろ。
—
まとめ
セキュリティは「チェックリスト」ではなく「アーキテクチャ」だ。
Hackの静的型システムを使いこなすということは、プログラムの「データの流れ」をコントロール下に置くということである。型チェッカーを単なるエラー発見器としてではなく、「ビジネスロジックの安全装置」として設計し直せ。
もし君のチームでまだ生の文字列をSQLクエリに流し込んでいるなら、それはコードを書いているのではなく、時限爆弾を組み立てているのと同じだ。今すぐ `newtype` で境界を引き、安全な設計へとアップデートしてほしい。
健闘を祈る。