SQLインジェクションとは？対策は？例を使って分かりやすく解説！

こんにちは。

SQLインジェクション、なんかの注射か？　と思っていたブログ担当もちゃじです。脆弱性の一つなんですってね。しかも三大脆弱性の一つに数えられる超メジャー級の脆弱性。

前回の記事（三大脆弱性の一つ消滅の危機！？ いやその前に、三大脆弱性って一体何？）では概要を書くにとどまりましたが、本記事ではSQLインジェクションをフィーチャーしていきます。もちゃじ同様、なんかの注射か？　と思ったそこのあなた（いるかな？）、一緒に勉強していきましょう。

データベースとSQLの関係

前段階としてデータベースとの関係を理解しないとなりません。例えばCMSを使ったブログやECサイトといったWebサイトには、データを入れておく「データベース」があります。

もちゃじが、趣味のブログをWordPressで作ったとしたら、もちゃじの投稿記事、コメント、いいねなどの情報は、全て「データベース」に格納されます。ECサイトを作ったら、商品情報や顧客情報、注文情報などのデータは全て「データベース」に格納されます。

そのデータベースを操作するために使うのが「SQL」です。

「SQL」はStructured Query Languageの略と、いわれたり、いわれなかったりするそうですが、とにかくデータベースとのやりとりに使う「言語」のことです。

また、「SQL文」というのがあります。これは、データベースへの「命令」のこと。もちゃじブログのデータベースに「昨日読んだ漫画を取り出してきて」というのがそれです。そうしたらデータベースは『DEATH NOTE』なのか『キングダム』なのか、該当のデータを出してきてくれます。

SQLインジェクションって何？

データベースとの関係が分かったところで、SQLインジェクションとは何かというと、「外部からSQL文を送信してWebアプリケーションのデータベースを不正に操作して攻撃されてしまう状態のこと（脆弱性）。またはその攻撃」をいいます。これ、データベースを直接操作されてしまうんです。不正なSQL文を注入（インジェクション）して攻撃。恐ろしいですよね。

どこから注入するかというと、検索ボックスや入力フォームなどからなんです。

SQLインジェクションの仕組みと命令文

知りたいことを検索ボックスから検索すると、サイトの裏側では検索ボックスに入力された文字を使ってSQL文が作られる仕組みになっています。

例えば読んだ漫画（仮に『キングダム』としましょう）の作者を知りたい場合は、SELECT文と呼ばれる「データを参照して持ってきて」というSQL文（命令）が設定されています。

例えば

SELECT * FROM 漫画テーブル WHERE タイトル＝'キングダム'

もしくは

SELECT 作者 FROM 漫画テーブル WHERE タイトル＝'キングダム'

初めてSQL文を見たもちゃじは？？？となりました。もちゃじレベルの人、離脱しないで〜。

何を意味するのか書きますね。

おお、そうすると、このSQL文が言いたいことが分かるじゃないかー。

SELECT * FROM 漫画テーブル WHERE タイトル＝'キングダム'

（訳：漫画テーブルから、全項目の情報を持ってきてね。ただし、タイトルがキングダムのものだけよ）

SELECT 作者 FROM 漫画テーブル WHERE タイトル＝'キングダム'

（訳：漫画テーブルから作者の情報を持ってきてね、ただしタイトルがキングダムのものだけよ）

そうすると、「原泰久」とデータベースが抽出してくれます。別の漫画タイトルを入力したら、「空知英秋」「美内すずえ」といった具合に。素直に指示通り動いてくれるデータベースさん。好き。

これを「悪意をもった人」が何かしてやろうと思った時、不正な文字で検索することで、設計者が意図していないSQL文を作ることができるんです。

設計者によって設定されているであろうSELECT文を予想して、検索値に、SQL文を一度終了する記号「’;」（シングルクォーテーション＋セミコロン）を入れる。これが入るとデータベースはユーザーの入力が終わったと見なします。そこで、続きに新しいSELECT文を入力する。

例えばこのような

SELECT * FROM 漫画テーブル WHERE タイトル＝'キングダム';SELECT * FROM もちゃじ隠し趣味テーブル;--'

そうするともちゃじが隠していた趣味テーブルのデータが出てきちゃうんです！
なんてことっ！

他には、

SELECT * FROM 漫画テーブル WHERE タイトル＝'キングダム' or '1'='1'

これは漫画テーブルが全部表示されてしまいます。

この「or ‘1’=’1’」は、WHEREの条件指定を全て無に帰すため、ログインIDやパスワードなどの不正取得で使われているようです。

これらは想定していない悪意のある情報が入力されてSQL文が生成・実行されてしまい、データの閲覧などができてしまうほんの一例です。データベースさん、素直すぎませんか？

上の例に出したselect（read）以外にも、主に以下三つの命令があります。

• insert：情報を追加
• update：情報を更新
• delete：情報を削除

なんとなく単語から内容の予想がつきますね。被害とともに見てみましょう。

(2022/10/3 追記）
SQLインジェクションのデモ動画を公開しました。こちらで具体的な手順をご覧いただけます。

要注意！　SQLインジェクションで想定される被害

どのようなWebサイトが狙われるかというと、データベースを使って情報を管理しているサイト、特に検索ボックスがあるサイトです。それらは攻撃対象に選ばれるようで、要注意です。

想定される被害を見てみると大きく四つあります。

データ改ざん、破壊、システムの乗っ取りなど

もちゃじブログの場合、推しへのほとばしる愛をつづった記事が削除されたり（deleteが考えられる）、憎悪に書き換えられたり（updateが考えられる）、反推し記事がアップされたら（insertが考えられる）……。顔出しNGで活動しているのに、プロフィール画面のイラストがリアルもちゃじの写真に変更されていたら（updateが考えられる）……、おおお恐ろしい!

アカウントの不正利用

IDやパスワードなどを入手し（selectが考えられる）、そのアカウントになりすましてECサイトなどで買い物されてしまったら……。　

個人情報・機密情報の漏えい

もちゃじの個人ブログだとインパクトがなさそうなので、ECサイトで考えてみます。それこそデータベースには、お客さまのお名前、住所、クレジットカード情報、購入商品などの絶対に外に漏らしてはならない個人情報・機密情報がモリモリ。それらが漏えいしたとしたら（selectが考えられる）、漏えいした個人情報を用いた2次被害も容易に想像がつきますよね。運営への信頼は当然ながら地に落ち、お客さまへの補償問題にも発展する恐れがあります。経営へのインパクト大です。

Webサイト改ざん

サイトの情報が書き換えられたり（updateが考えられる）、削除されたり（deleteが考えられる）してしまったら……。もちゃじブログならたかが知れていますが、企業のコーポレートサイトだったら大問題です。

ユーザーに罠を踏ませる手順も必要なく、攻撃者だけで攻撃が成立してしまう。どれだけ恐ろしいんだよ、SQLインジェクション攻撃。

対策は？

超メジャーなSQLインジェクションですから、対策ももちろんあります。ここでは三つ、解説します。

1.最も効果的！エスケープ処理とプレースホルダ

これをすれば、SQLインジェクションの脆弱性はなくなる、といわれているエスケープ処理。根本的に解決しちゃうらしいです。特別な意味をもつ記号を普通の文字として処理させてしまうんですって。

例えば、先ほどもちゃじの隠しテーブルのデータを出してきた憎いあいつ「SQL文を一度終了する記号「’;」（シングルクォーテーション＋セミコロン）」。これをデータベースさんに記号ではなく、ただの文字と認識してもらえばいいんです。そうしたら「SQL文を一度終了する処理」がされないんです。
もちゃじレベルの人〜、ついてきてくださ〜い。

「普通の文字として処理する」というのが、どういうことかというと、

（先ほどのSQL文）

SELECT * FROM 漫画テーブル WHERE タイトル＝'キングダム'; SELECT * FROM もちゃじ隠し趣味テーブル;--'

（訳：漫画テーブルから、全項目の情報を持ってきてね。ただし、タイトルが『キングダム』のものだけよ、追加で、もちゃじ隠し趣味テーブルから全ての項目を持ってきてね）

この「;」をデータベースさんが記号と認識しないように、プログラム側でSQL実行前に「’」（シングルクォーテーションをエスケープして「’」も「;」（セミコロン）も文字として認識させてしまえばいい。ここでの元凶は「’」。

「’」をエスケープする方法は、二つ重ねる！これだけ！

すると、こうなります。

SELECT * FROM 漫画テーブル WHERE タイトル＝'キングダム''; SELECT * FROM もちゃじ隠し趣味テーブル;--'

（訳：漫画テーブルから、全項目の情報を持ってきてね。ただし、タイトルが「キングダム’; SELECT * FROM もちゃじ隠し趣味テーブル;– 」のものだけよ）

データベースさん、素直。すてき。なんのこっちゃになりますね。これが無効化。

こういった「‘’（シングルクォーテーション）」「“”（ダブルクォーテーション）」など、SQLに関わるような特殊文字を無効化して（文字として扱う）、不正な値が入力されてもSQLとして実行されることを防ぎます。

さて、次はプレースホルダ。

これは、独自処理することによって、エスケープ処理すら必要なくなるすごいやつ。これもデータベースさんが活躍してくれるんです。

あらかじめ同じような質問を何回もデータベースさんにするだろうと想定して、SQL文を穴埋めのひな型で作っておきます。穴埋め部は「？」などの特殊文字を仮に入れておきます。

そしてデータベースさんに「『これからXの作品を何作品読んだ？』と聞いていきます。『X』はその都度指示するので、あなたの方でうまく引っ張ってきて答えてね」と話をつけておきます。

もちゃじ：「X＝鳥山明」（作者が鳥山明の作品を何作品読んだ？）
データベース：2作品です。
もちゃじ：「X＝あだち充」（作者があだち充の作品を何作品読んだ？）
データベース：8作品です。

というように。

Xに入力された値をバインド変数といい、ベースのSQL文に仮置きしてある「？」の変動箇所（プレースホルダ）に差し込まれる形でSQL文を生成します。この入力値に悪意ある特殊な記号があっても、単なる値としてデータベースに渡されるため、悪意あるSQL文は作られない、ということです。

急にワードが難しくなりましたね。もちゃじもいっぱいいっぱいです。

2.従来型の対策！ホワイトリストの設定

入力されるだろうワードを想定してリスト化し、それ以外ははじく、というもの。

IDやパスワードなど、使用されると考えられる「英数字日本語カナ＋一部の記号」をリスト化します。リスト化は安全な文字のみ許可されるので、とても効果的な方法といわれています。

ホワイトリストに対してブラックリストという対策もあります。こちらは、SQL文に影響しそうな悪意ある値をリスト化してはじく、というもの。具体的には、SQL文を構成するワードや記号をブラックリストとして設定しておくことで、それらが入力されたらはじきます。ただ、抜け漏れも多く、対策としては不十分だそう。

それにしてもホワイトとブラックって対になって出てきますよね、セキュリティワード。ホワイトボックス、ブラックボックスも以前出てきました。

3.補足的に！必要最小限の権限付与

アクセス権、更新権などを管理者のもちゃじユーザーだけにして、他の検索するためのユーザーは参照だけの権限付与にとどめる、など。触れる人が増えるほどリスクも大きくなりますよね。

まとめ

三大脆弱性の一つSQLインジェクションとは、「外部からSQL文を送信してWebアプリケーションのデータベースを不正に操作して攻撃されてしまう状態のこと（脆弱性）。またはその攻撃」のことでした。

その被害は「データ改ざん、破壊、システム乗っ取り」「アカウント不正利用」「個人情報・機密情報の漏えい」「Webサイト改ざん」といった深刻なものです。

大きな被害をもたらすメジャーな脆弱性ですが、しっかりとした対策を行えばSQLインジェクション攻撃を受けるような脆弱性は解消されることも分かりました。

具体的には　「エスケープ処理やプレースホルダ」「ホワイトリストの設定」「必要最小限の権限付与」。これらの対策を行い、想定外の情報が入力されてもデータベースにSQL文を実行させないことで、SQLインジェクションの脆弱性が存在しない安全なWebサイトになります。

SQLインジェクションの脆弱性が存在しない安全なWebサイトを開発するのが一番の対策なのですが、既に存在しているWebサイトにSQLインジェクションの脆弱性があるかどうか、一度脆弱性診断をしてみるのもオススメです。（と、弊社信興テクノミストの脆弱性診断を宣伝してみる）

今回出てきた用語

ふう、書き終えた

もちゃじのプライベート趣味ブログ、読みたいな。誰か書いてくれないかな。

ライター／もちゃじ

IT業界に縁なく秘書畑をさすらい、前職はインドで社長秘書。ほぼ日本語とパッションのみで乗り切ったずうずうしさはスキルの一つか。完全なインドア派ながらたまにふらりと旅に出る。行き場のない母性を持て余し、友人の犬を溺愛するもほえられる。体が硬く、インドでヨガティーチャーに笑われたことに深く傷つく一面も。

ITド素人の私がWebセキュリティについて学び、レベルアップしていく（予定です）様子をお届けします。学びを発信することで、少しでもWebセキュリティに関する「難しそう」というイメージが下がり、苦手意識のある方たちに届いたらうれしいです。