インジェクション攻撃

インジェクション攻撃とは、アプリケーションがユーザー入力をコマンドやクエリとして解釈することによって発生する脆弱性の総称であり、SQLインジェクションはOWASP Top 10の最上位に長年位置してきた最も危険な脆弱性カテゴリである。攻撃者は入力フィールドに特殊文字やコマンド断片を挿入することで、意図しないSQLクエリ・OSコマンド・LDAPクエリ等を実行させることができる。インジェクション攻撃の共通した防御原則は、データとコードを明確に分離し、ユーザー入力をコードとして解釈させないことである。

SQLインジェクションの唯一の確実な対策はパラメータ化クエリ（プリペアドステートメント）であり、ユーザー入力が常にパラメータとして扱われSQL構文の一部にならないことを保証する。ORMや文字列エスケープによる対策は、設定ミスや特殊なケースで機能しないことがあるため、パラメータ化クエリを基本とすることが推奨される。コマンドインジェクションはexec()・eval()・shell_exec()などのシェル実行関数にユーザー入力を渡すことで発生し、OSコマンドの任意実行につながる最も危険なインジェクションの一つである。

NoSQLデータベース（MongoDB等）も$where・$gt等のクエリオペレータを使ったインジェクションが可能であり、「SQLを使っていないから安全」という思い込みは危険である。2次インジェクション（Second-Order Injection）は、DBに一度保存された入力値が別のクエリで安全でない方法で使われる際に発生する問題であり、データの保存時ではなく利用時にパラメータ化が必要になるケースである。

コードレビューで着目するポイント

DBクエリがすべてパラメータ化クエリまたはORMの安全なメソッドで構築されているか（文字列連結でのクエリ組み立てがないか）
exec()・child_process.exec()・subprocess.call()等の関数にユーザー入力が直接渡されていないか
ORM利用時に生のクエリ文字列を使うraw()・query()等のメソッドがパラメータ化されているか
MongoDBなどNoSQLのクエリでユーザー入力がオペレータ（$where・$gt等）として解釈されないようになっているか
LDAP検索フィルタにユーザー入力が含まれる場合、適切なエスケープが行われているか
XMLを処理する際にXXE（XML External Entity）対策として外部エンティティ処理が無効化されているか

典型的なアンチパターン

文字列連結によるSQL組み立て: "SELECT * FROM users WHERE name = '" + userName + "'" のように文字列連結でクエリを組み立てる実装。userNameに ' OR '1'='1 を入力されると全レコードが返ってしまう。プリペアドステートメントでWHERE name = ?と記述し、入力値はパラメータとして渡すこと。

shell経由の外部コマンド実行: exec("convert " + userFileName) のようにユーザー指定のファイル名をコマンドに含める実装。userFileNameにimage.jpg; rm -rf /を指定されるとOSコマンドが実行される。コマンド実行が必要な場合は引数配列形式（execFile(cmd, [arg1, arg2])）を使いシェル解釈を避けること。

ORMのraw()への無検証入力: ORMで通常は安全に処理されるが、複雑なクエリのためにUser.query("WHERE " + userFilter)のようにraw文字列メソッドにユーザー入力を直接渡す実装。ORMの安全なAPIを使って表現できない場合もパラメータ化は維持できる。

参考リソース

OWASP SQL Injection Prevention Cheat Sheet — SQLインジェクション防御の包括的ガイド
OWASP Command Injection Defense Cheat Sheet — コマンドインジェクション防御の実装ガイド
OWASP Top 10: A03 Injection — インジェクション脆弱性の最新分類と事例
SQLMap (https://sqlmap.org/) — SQLインジェクション自動検出ツール（ペネトレーションテスト用）
Bobby Tables (https://bobby-tables.com/) — SQLインジェクション対策の言語別サンプルコード集