SQLインジェクションとは？仕組みと対策を解説

SQLインジェクションとは、Webアプリケーションが受け取った入力値を安全に処理せず、そのままSQL文の一部として扱ってしまうことで、意図しないデータベース操作につながる脆弱性です。

対策の中心は、入力値をSQL文へ文字列連結しないことです。 プリペアドステートメント（パラメータ化クエリ）を使い、SQLの構造とデータを分離することで、入力値がSQL命令として解釈されにくくなります。

SQLインジェクションとは？

SQLインジェクションは、Webアプリケーションとデータベースの間でSQL文を組み立てる処理に問題があるときに起こる代表的なインジェクション脆弱性です。

OWASPでは、信頼できないデータがSQL構文の一部になることで、データの閲覧・変更などにつながる可能性があると説明しています。

SQLとは？

SQLは、MySQLやMariaDB、PostgreSQLなどのリレーショナルデータベースへ命令を送るための言語です。

WordPressも投稿、ユーザー、設定などのデータをデータベースへ保存しており、必要に応じてSQLを通じて読み書きします。

SQLインジェクションはなぜ起きる？

典型的な原因は、ユーザーが入力した値をSQL文字列へ直接連結してしまうことです。

SQL文 = "SELECT ... WHERE name = '" + ユーザー入力 + "'"

このようにSQLの構造と入力値が混ざると、入力内容によってSQL文の意味そのものが変わる可能性があります。

どんな入力欄が関係する？

SQLインジェクションは、検索ボックスやログインフォームだけで起こるわけではありません。 入力値がSQLへ使われる場所なら、さまざまな経路が対象になります。

「外部ユーザーが直接入力する画面だけ見ればよい」とは限りません。 OWASPも、別サービスや保存済みデータなど、信頼できない値がSQL構築へ入るケースを含めて対策するよう案内しています。

SQLインジェクションで起こり得る被害

脆弱性の内容やデータベース権限によって影響は変わります。

影響範囲は、アプリケーションがデータベースへどの権限で接続しているかによっても変わります。

最重要対策はプリペアドステートメント

OWASPが最優先の対策として推奨しているのが、プリペアドステートメントとパラメータ化クエリです。

SQL文の形を先に固定し、ユーザー入力は「データ」として別に渡します。 これにより、入力値がSQL命令の構造を変更しにくくなります。

SELECT ... WHERE name = ?
↓
? の部分へ値をデータとして渡す

重要なのは、入力値をSQL文字列へ直接埋め込まず、データベースAPIのパラメータ機能を利用することです。

プリペアドステートメントならなぜ安全？

プリペアドステートメントでは、SQLの命令部分と値部分を分けて扱います。 そのため、値として渡された文字列は基本的に「SQL構文を変更する命令」ではなく「検索・保存対象のデータ」として扱われます。

入力チェックだけでは不十分

「英数字だけ許可する」「文字数を制限する」といった入力バリデーションは重要ですが、SQLインジェクションの主防御としては不十分です。

OWASPも、入力検証はパラメータ化クエリを補助する対策であり、値を検証したからといってSQLへ直接連結してよいわけではないと説明しています。

エスケープだけに頼らない

特殊文字をエスケープしてSQL文字列へ入れる方法もありますが、OWASPは手動エスケープをプリペアドステートメントの代替として使うことを強く推奨していません。

データベース製品や設定によってエスケープ規則が異なるため、実装ミスが起こりやすいからです。

テーブル名や並び順はどう扱う？

パラメータ化できるのは主にデータ値です。 テーブル名、カラム名、並び順などSQL構造そのものをユーザー入力で自由に決めさせる設計は避けます。

OWASPでは、このような構造部分はアプリケーション側で用意した許可リストから選ぶ方法を推奨しています。

データベース権限を最小限にする

SQLインジェクションそのものを防ぐ対策とは別に、万一脆弱性が悪用された場合の被害を小さくするため、DB接続ユーザーの権限を必要最小限にします。

OWASPも、WebアプリケーションのDB接続にDBAや管理者相当の権限を与えないよう推奨しています。

WAFはSQLインジェクション対策になる？

WAFは、Webアプリケーションへ届くHTTP/HTTPSリクエストを検査し、SQLインジェクションなどの既知攻撃パターンを検知・遮断する防御層として役立ちます。

WordPressではSQLインジェクションをどう防ぐ？

WordPress本体にはデータベースを安全に扱うためのAPIが用意されています。 テーマやプラグイン開発では、可能な限りWordPress標準関数を使い、独自SQLが必要な場合は $wpdb の安全な機能を利用します。

$wpdb->prepare()とは？

$wpdb->prepare() は、WordPressでSQLクエリを安全に準備するためのメソッドです。 値をプレースホルダーへ渡すことで、SQL文とデータを分離します。

global $wpdb;

$sql = $wpdb->prepare(
    "SELECT * FROM {$wpdb->posts} WHERE ID = %d",
    $post_id
);

WordPress公式では、%d は整数、%f は浮動小数点数、%s は文字列など、用途に応じたプレースホルダーを利用できます。

WordPress標準APIを使う

投稿メタの保存、ユーザー情報、オプション設定など、WordPressには多くの操作用APIがあります。

WordPress公式のテーマセキュリティガイドでも、WordPress関数が用意されている場合はそれを使うことが第一の方針として案内されています。

WordPress利用者はテーマ・プラグイン更新も重要

自分でSQLを書かないWordPress利用者でも、テーマやプラグイン側にSQLインジェクション脆弱性が見つかる可能性があります。

一般利用者はSQL文を自分で修正するより、脆弱性修正版を速やかに適用できる運用の方が重要です。

SQLインジェクションとXSSの違い

SQLインジェクションとXSSは、どちらも入力処理の問題に関係しますが、狙う場所が違います。

SQLインジェクションはデータベース側、XSSは主にブラウザ側で問題が発生するため、防御方法も異なります。

SQLインジェクションとCSRFの違い

どちらもWebアプリケーションの脆弱性ですが、成立条件と対策は別です。

入力サニタイズだけで防げる？

入力値を整形・検証するサニタイズやバリデーションは重要ですが、それだけをSQLインジェクション防御の中心にしてはいけません。

1つの対策ですべてを防ぐのではなく、複数層で守ります。

データベースをroot権限で使わない

Webアプリケーションからデータベースへ接続するとき、DB管理者相当の強い権限を与えるべきではありません。

SQLインジェクションが成立した場合でも、接続ユーザーが必要最小限の権限しか持っていなければ、被害範囲を限定できる可能性があります。

エラーメッセージの公開にも注意する

本番サイトで詳細なデータベースエラーやSQL文を画面へ表示すると、内部構造に関する不要な情報を外部へ見せる可能性があります。

脆弱性診断では何を確認する？

自社開発のWebアプリでは、コードレビューやセキュリティ診断でSQLの組み立て方を確認します。

攻撃手順を本番環境で試すのではなく、許可されたテスト環境・診断手順で確認します。

SQLインジェクションが疑われるときの対応

改ざんや不審なDB操作が疑われる場合は、原因確認と封じ込めを優先します。

一般的なWordPress利用者は何をすればよい？

自分でプラグインやテーマを開発していない場合、SQLコードを直接確認する必要は通常ありません。

やってはいけない対策

危険文字をブラックリストで全部禁止する

文字の禁止だけでは抜け漏れが起きやすく、正常入力まで壊す可能性があります。パラメータ化を基本にします。

XSSとは？クロスサイトスクリプティングの仕組みと対策

XSS（クロスサイトスクリプティング）とは、Webページへ意図しないスクリプトなどが入り込み、閲覧者のブラウザ上で実行される脆弱性・攻撃の総称です。お問い合わせ内容、コメント、検索キーワード、URLパラメータなど、外部から受け取った値を安全に処理せずHTMLへ出力すると、文字列として表示すべき内容がブラウザにコードとして解釈される可能性があります。WordPress運営者にとって重要なのは、攻撃方法を覚えることではありません。WordPress本体・テーマ・プラグインを更新し、開発側では入力検証・サニタイズ・出力時エスケー...

CSRFとは？仕組みと対策を初心者向けに解説

CSRF（Cross-Site Request Forgery）は、ログイン中のユーザーに対して、本人が意図していない操作をWebサイト上で実行させる攻撃です。たとえば、管理画面へログインしたまま別サイトを開いたとき、そのページから意図しない変更リクエストが送られると、ブラウザがログイン情報を自動で付けてしまい、正規ユーザーの操作として処理される可能性があります。初心者は、「ログイン中の権限を悪用して、勝手な操作をさせる攻撃」と理解すると分かりやすいです。30秒でわかる結論30秒でわかる結論CSRFは、ログイン中ユーザーに意図しない...

WAFがあるからコードを直さない

WAFは追加防御です。脆弱なSQL実装は修正してください。

レンタルサーバーのセキュリティ完全ガイド

レンタルサーバーのセキュリティ対策は、1つの機能を有効にすれば終わるものではありません。Webへの攻撃を防ぐ仕組み、管理画面への不正ログイン対策、安全なファイル転送、パスワード管理など、守る場所ごとに必要な対策が異なります。このページでは、レンタルサーバーのセキュリティを「何から守るか」「どの機能を使うか」「どの順番で確認するか」に分けて整理します。WAFやSSHなどの細かな仕組みは一般記事へ譲り、ここでは全体像と判断基準をつかむことを目的にします。30秒でわかる結論最初に「サーバー会社が守る範囲」と「...

ユーザー入力を自作エスケープして連結する

データベースごとの仕様差や実装ミスがあるため、標準のパラメータ機能を利用します。

DB接続を管理者権限にする

侵害時の被害範囲が大きくなります。必要最小限の権限を設定します。

本番で詳細なSQLエラーを公開する

内部構造を外部へ見せる可能性があります。詳細はログで確認します。

教科書判定

FAQ

まとめ