SQLインジェクションとは何か。仕組み・攻撃手法・影響・対策を原理から徹底解説

SQLインジェクションは、登場から20年以上たった今もWebアプリケーションの代表的な脆弱性であり続けています。古典的でありながら、攻撃が成立すればデータベース全体の漏えいや改ざん、さらにはサーバーの乗っ取りにまでつながる影響の大きさから、いまも国内外で繰り返し被害が報告されています。OWASP Top 10でも、インジェクションは長年にわたり上位カテゴリに位置づけられてきました。

やっかいなのは、対策そのものは確立されていて難しくないにもかかわらず、いざ開発の現場になると「とりあえず動くSQL」を文字列連結で書いてしまい、脆弱性が作り込まれ続けている点です。この記事では、なぜこの脆弱性が生まれるのかという原理から、攻撃手法の分類、想定される影響、そして根本対策と多層防御までを、順を追って体系的に整理します。

なぜSQLインジェクションは起きるのか#

問題の本質は、SQL文という「命令」と、利用者が入力した「データ」を、文字列連結で混ぜてしまう点にあります。アプリケーションが次のようにSQL文を組み立てているとします。

SELECT * FROM users WHERE name = '入力値';

ここで利用者が name に ' OR '1'='1 という文字列を入力すると、組み上がるSQL文は次のようになります。

SELECT * FROM users WHERE name = '' OR '1'='1';

'1'='1' は常に真になるため、本来1件も返らないはずの条件がすべての行に一致してしまいます。データベースから見れば、これは「正しい構文のSQL文」であり、どこまでが開発者の意図した命令で、どこからが利用者の入力なのか、知るすべがありません。命令とデータの境界が、文字列連結という操作によって壊されてしまったのです。これがSQLインジェクションの核心です。

重要なのは、これが「特定の文字をうっかり通してしまった」という表層的な問題ではなく、「命令とデータを混ぜて文字列として組み立てている」という構造的な問題だという点です。だからこそ、後述するように個別の文字をエスケープして塞ぐ発想ではなく、そもそも命令とデータを分離する発想が必要になります。

攻撃手法の分類#

SQLインジェクションと一口に言っても、攻撃者が結果をどう受け取るかによっていくつかの型に分かれます。代表的なものを整理します。

ここで強調したいのは、ブラインドSQLインジェクションの存在です。「画面にデータベースの内容を表示していないから安全」という思い込みは誤りです。応答の真偽や時間差だけを手がかりに、攻撃者は1文字ずつデータを復元できます。時間はかかりますが、自動化ツールを使えば現実的な時間で大量のデータが抜き取られます。

想定される影響#

SQLインジェクションが成立したときの影響は、単なる情報漏えいにとどまりません。

特に、データベースに保存された認証情報が漏えいすると、それ自体の被害に加えて、利用者がパスワードを使い回していた場合に他サービスへの被害（いわゆるリスト型攻撃）へと連鎖します。SQLインジェクション一件が、組織の信用とユーザーの安全の両方を一度に損なう可能性があるということです。

実際の攻撃はどう進むか#

攻撃者は、いきなり全データを抜くわけではありません。典型的には次のような段階を踏みます。

防御側の視点では、この各段階で痕跡が残ります。次々とエラーを誘発するリクエストや、UNION SLEEP information_schema といった文字列を含むリクエストは、検知の手がかりになります。

根本対策: プレースホルダ（プリペアドステートメント）#

最も確実な対策は、SQL文の「構造」と「値」をデータベースドライバのレベルで分離することです。これをプレースホルダ、またはプリペアドステートメントと呼びます。あらかじめ「ここに値が入る」という穴あきのSQL文をデータベースに渡し、値はあとから別経路で渡します。値はどこまでいっても値として扱われ、SQL文の構造を書き換えることはできません。

主要な言語での書き方を見てみましょう。考え方はどの言語でも同じです。

# Python（悪い例: 文字列連結で脆弱）
cursor.execute("SELECT * FROM users WHERE name = '" + name + "'")

# Python（良い例: プレースホルダ）
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

// PHP（PDO のプリペアドステートメント）
$stmt = $pdo->prepare('SELECT * FROM users WHERE name = :name');
$stmt->execute([':name' => $name]);

// Java（PreparedStatement）
PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();

いずれも、値の中身がどんな文字列であっても、それは常に「値」として扱われます。' OR '1'='1 を入れても、それは「' OR '1'='1 という名前を探す」という検索になるだけで、SQL文の論理は一切変わりません。これが根本対策である理由です。

OWASPのSQL Injection Prevention Cheat Sheetは、第一の防御として一貫してプリペアドステートメント（パラメータ化クエリ）の利用を挙げています。

値として渡せない部分の扱い#

注意したいのは、テーブル名・カラム名・ORDER BY の方向（昇順/降順）など、SQLの「構造」に当たる部分はプレースホルダの値として渡せないという点です。たとえば並び替えのキーをユーザーに選ばせる機能では、受け取った文字列をそのままSQLに埋めるのではなく、あらかじめ許可するカラム名のリストを用意し、その中に含まれる場合だけ使う「許可リスト方式」で対応します。

# 許可リスト方式: 構造部分は受け取った値をそのまま使わない
ALLOWED_SORT = {"created_at", "name", "price"}
sort_key = sort_key if sort_key in ALLOWED_SORT else "created_at"

よくある誤解と、やってはいけない対策#

SQLインジェクション対策には、効果が限定的だったり、かえって危険だったりする「やりがちな対処」があります。

• エスケープだけで済ませる: 入力に含まれるシングルクォートをエスケープする方法は、対象のDBや文字コード、文脈ごとに正しく行う必要があり、抜けや回避が生じやすい方法です。多層防御の一つにはなりますが、根本対策にはなりません。
• ブラックリストで危険な単語を弾く: SELECT や UNION といった単語を禁止する方法は、大文字小文字の混在、コメントの挿入、エンコードなどで容易に回避され、かつ正規の入力まで弾いてしまいます。
• ストアドプロシージャを使えば安全という思い込み: ストアドプロシージャの内部で動的SQLを文字列連結で組み立てていれば、同じように脆弱です。安全なのはプロシージャだからではなく、パラメータ化されているからです。

つまり、対策の良し悪しは「危険な入力を頑張って取り除いているか」ではなく、「命令とデータが構造的に分離されているか」で判断するのが正しい見方です。

多層防御: 根本対策に重ねる備え#

プレースホルダを徹底したうえで、万一の取りこぼしや別経路の侵入に備えて、次の多層防御を重ねます。

これらはいずれも単独では破られうるため、あくまで根本対策の上に積む「保険」と位置づけます。最小権限は特に重要で、仮に侵入されても、アプリ用ユーザーにテーブル削除やOS連携の権限がなければ被害を限定できます。

ORMを使っている場合の注意#

近年の多くのフレームワークはORM（オブジェクト関係マッピング）を備えており、通常の操作では内部でパラメータ化が行われるため、安全側に倒れます。ただし油断は禁物です。

• 生SQL（raw query）を書く機能を使う箇所は、結局自分でパラメータ化する責任が残ります。
• 検索条件やソートを文字列として組み立てて渡すインターフェースは、使い方次第で脆弱になります。
• ORMが提供する「文字列をそのまま埋め込む」系のメソッドは、名前のとおり危険です。

ORMを使っているからと一律に安全とみなさず、生SQLや動的なクエリ生成を行っている箇所を洗い出して個別に確認してください。

検出とテスト#

導入後は、脆弱性が残っていないかを確認します。

よくある質問#

まとめ#

仕組みを理解すれば、SQLインジェクションは「命令とデータを分離する」という一点に集約されることが見えてきます。個別の文字を頑張って取り除くのではなく、そもそも混ざらない設計にする。これがすべての出発点です。関連して、より広いWeb脆弱性の全体像は