インジェクションとは
インジェクション（A05）は、利用者が入力した文字がそのままプログラムの命令として実行されてしまう弱点です。
OWASPは、「信頼できない入力がインタープリター（ブラウザ、データベース、コマンドラインなど、命令を解釈して実行するもの）に渡され、入力の一部が命令として実行されてしまう」弱点と説明しています [V2]。
OWASPによるとインジェクションは、調べられた対象の100%で何らかの形が検査されている項目で、すべての項目の中で最も多くの脆弱性の番号（CVE）が付いています。
クロスサイト・スクリプティング（XSS）は件数が多い一方で、1件あたりの影響は比較的小さく、SQLインジェクションは件数は少なめですが、1件あたりの影響が大きいとされています [V2]。
SQLインジェクションの例
SQLはデータベースに命令するための言語です。
OWASPは、利用者の入力を命令の文字列にそのままつなげて作る書き方の例を挙げています。次のような、入力された「id」をそのまま命令に埋め込むプログラムです [V2]。
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; 攻撃者が、idに「’ OR ‘1’=’1」という文字を入力すると、以下のようなSELECT文になってしまいます。
これは「custIDが空」または「1と1が等しい（抽出しようとしている*の1列目と1列目が等しい＝すべてのレコードが必ず一致するため全量取得できる）」を意味し、データベースの口座の情報がすべて返ってしまいます。
SELECT * FROM accounts WHERE custID='' OR '1'='1';さらに危険な攻撃では、データの変更や削除につながる場合もあります [V2]。
防ぐ方法：データと命令を分ける
OWASPは、最も良い防ぎ方は「データを命令やクエリ（問い合わせ）と分けておくこと」だと述べています [V2]。
具体的には、次のとおりです。
- 安全な仕組みを使う：命令の解釈器をそもそも使わない書き方や、「パラメータ化」（命令の形を先に決めてデータは後から別に渡す方法）またはORM（オブジェクト関係マッピング、プログラム上のオブジェクトとデータベースのテーブルを自動で結びつけ、SQL文を書かずにデータベースを操作できるようにする仕組み・技術）を使う [V2]
- 分けられない場合：サーバー側で、入力が許される内容かを確認する（完全な防御ではない）。特別な文字の処理（エスケープ）も併用する。ただし、これらは複雑で間違いやすく、システムの変更に弱いとOWASPは警告しています [V2]
日本のIPAも同じ考え方です。
IPAのチェックリストでは、SQL文の組み立てはすべて「プレースホルダ」（データを入れる場所をあらかじめ空けておく方法）で実装することが「根本的解決」として挙げられています。
一方、エラーメッセージをそのままブラウザに表示しないことや、データベースのアカウントに適切な権限を与えることは「保険的対策」と分類されています [V5]。
OSコマンドや、命令の種類は、SQLだけではない
OWASPは、よくあるインジェクションとしてSQL、NoSQL、OSコマンド、ORM、LDAP、式言語のインジェクションを挙げ、考え方はどの解釈器でも同じだとしています。
OSコマンドの例では、ドメイン名を入力する機能に「example.com; cat /etc/passwd」と入力するとサーバーの重要なファイルが読まれてしまう、という例が示されています [V2]。
AIにも、同じ構造がある
OWASPは、同じ性質の問題がLLM（生成AI）でも一般的になっていると述べ、別の一覧（OWASP LLM Top 10）のプロンプトインジェクションで扱うとしています [V2]。
生成AIの記事でも説明している内容です。
XSS・CSRF・クリックジャッキング
IPAの資料では、XSS（クロスサイト・スクリプティング）、CSRF（クロスサイト・リクエスト・フォージェリ）、クリックジャッキングも、取り上げられています [V5]。
名前は難しいですが、いずれも、「利用者の画面や、操作を悪用される」タイプの弱点です。
- XSS：攻撃者が仕込んだ文字（スクリプト）が、他の利用者の画面で実行されてしまう。OWASPは、インジェクションの一種として扱っている [V2]
- CSRF：ログイン中の利用者の操作に見せかけて、勝手にリクエストを送らせる。IPAの資料では、処理を実行するページをPOSTメソッドでアクセスするようにし、前のページでhiddenパラメータに秘密情報を出力、実行ページでhiddenパラメータと突合をかけ不一致の場合は処理を行わない、などの対策方針を示している [V5]
発注の前に確認したいこと
- データベースを呼び出すところは、パラメータ化（プレースホルダ）されているか。文字をつなげて命令を作っていないか
- 入力の確認は、サーバー側で行っているか。画面側だけに頼っていないか
- エラーメッセージが、そのまま画面に出ていないか。データベースのアカウントに、必要以上の権限を与えていないか
注記：この3点は、OWASPとIPAの内容から整理した確認項目です。
参照元
[V2] OWASP, Top 10:2025 — A05 Injection — https://owasp.org/Top10/2025/A05_2025-Injection/
[V5] IPA（情報処理推進機構）, 安全なウェブサイトの作り方 — https://www.ipa.go.jp/security/vuln/websecurity.html
コメント