DASTは「魔法の杖」じゃない。実行時インジェクション検知の限界と突破口
現場のエンジニア諸君、お疲れ様。今日もどこかのサーバーで、悪意あるクエリがデータベースの扉をノックしているはずだ。
「DAST（動的解析ツール）を回してるからうちは安泰だ」と考えているなら、今すぐその考えを捨ててほしい。DASTは確かに強力だが、それは「外から見える地雷」を教えてくれるだけのガイドに過ぎない。今日は、DASTの本当の立ち位置と、泥臭いインジェクション対策の核心について話そう。
1. DASTとペネトレーションテストの「決定的な違い」
DAST（Dynamic Application Security Testing）は、いわば「自動化された巡回パトロール」だ。稼働中のアプリに大量のペイロードを投げ込み、レスポンスの遅延やエラーコードを見て「ここ、穴が開いてるかもよ？」と教えてくれる。
一方、ペネトレーションテストは「侵入を目的とした狙撃手」だ。彼らはDASTが検知できない「ビジネスロジックの脆弱性」や「認証のバイパス」を見つけ出す。DASTがカバーするのは「既知の攻撃パターンへの耐性」であり、アプリケーションの「設計上の欠陥」までは見抜けない。
DASTで脆弱性が見つからないからといって、システムが安全だと安心するのは、鍵のかかっていない窓を「開いていないから大丈夫」と言っているのと同じだ。
2. インジェクションの現場：DASTが見ている「その先」
例えば、SQLインジェクションを狙うDASTは、' OR 1=1 -- のような古典的なペイロードをパラメータに注入してくる。しかし、現場の攻撃者はそんな単純なことはしない。WAFを回避するためにエンコーディングを重ねたり、Blind SQLiを使って1文字ずつデータを盗み出したりする。
脆弱な実装例（悪い見本）
// 最悪のパターン：ユーザー入力をそのままクエリに結合
$id = $_GET[‘id’];
$query = “SELECT FROM users WHERE id = ” . $id; // ここでDASTが「ビンゴ！」と叫ぶ
$result = $db->query($query);
このコードに対し、DASTは「レスポンスが変わった」と報告する。だが、本番環境でこれを防ぐために必要なのは、ツールを回すことではなく、「クエリとデータの分離」だ。
3. 実践：インジェクションを根絶する実装ルール
対策は「プリペアドステートメント（静的プレースホルダ）」の一択だ。これ以外に道はない。
セキュアな実装例（PHP/PDO）
// プリペアドステートメントで実行計画を固定する
$id = $_GET[‘id’];
$stmt = $pdo->prepare(“SELECT FROM users WHERE id = :id”);
// 値をバインドする際、型が強制されるため悪意あるコードはただの文字列として扱われる
$stmt->bindParam(‘:id’, $id, PDO::PARAM_INT);
$stmt->execute();
Node.js（Express + pg）の場合
const query = ‘SELECT FROM users WHERE id = $1’;
const values = [req.params.id];
// クエリ構造を分離して実行することでインジェクションを無効化
const res = await client.query(query, values);
4. インフラ側での「最後の砦」：Nginx + WAFの設定
アプリ側の修正が完了するまでの「応急処置」として、あるいは多層防御の一環として、エッジ側でのフィルタリングは必須だ。Nginx + ModSecurity（あるいはAWS WAF等のマネージドサービス）で、不審なメタ文字を遮断する設定を入れよう。
Nginx設定イメージ（ModSecurityルール例）
悪意あるSQLiペイロードを検知してブロックするルール設定
実際にはOWASP Core Rule Set (CRS)の利用を強く推奨する
SecRule ARGS “@rx (?i)union.select” \
“id:1001,phase:2,deny,status:403,msg:’SQL Injection Attempt Detected'”
5. 現場のチーフからの提言
DASTは「開発の最終チェック」として使うべきではない。真の目的は、「修正されたコードが本当に効いているか」の検証だ。
1. DASTをCI/CDパイプラインに組み込む： 開発環境でビルドするたびに、まずは軽めのスキャンを通す。
2. 脆弱性の「根本」を叩く： DASTの結果を鵜呑みにせず、コードレビューで「ユーザー入力がどこでクエリになるか」を追跡する。
3. WAFは「傘」である： WAFで攻撃を止めるのは当然だが、それは雨（攻撃）が降った時の対策に過ぎない。アプリケーションという家自体を、雨漏りしない堅牢な設計にすることが、我々エンジニアの責務だ。
セキュリティとは、ツールを導入して安心する作業ではない。「悪意ある入力は必ずやってくる」という前提で、コードを書き続ける執念そのものだ。
次回のデプロイ時、君たちのコードが脆弱性診断を軽々とクリアし、かつ設計としても美しいものであることを期待している。何かあればいつでも相談してくれ。
コメント