「SQLインジェクションにはどのようなリスクが潜んでいる？」
「SQLインジェクション対策をしたいが何から取り組むべき？」
SQLインジェクションは、攻撃された場合にデータベースの不正な操作を許してしまう脆弱性です。脆弱性対策をしていないと、不正アクセスや情報漏えいのリスクが想定されるため非常に危険です。
そこで、本記事では以下の内容について紹介します。
- SQLインジェクションの概要
- 起こりうる被害
- 効果的な対策
自社に合ったSQLインジェクション対策を立てるヒントが見つかるので、ぜひ参考にしてください。
データベース言語にSQLを採用している企業の方、必見！
SQLインジェクションの対策は、何から取り組むべき？
エスケープ処理やアクセス制御・暗号化などの基本的な対策を実施することが必要不可欠です。また、漏れなく対応するためには、Webシステム全体の脆弱性をチェックし、最適な対策を実施する工程を加えましょう。まずは、サービス紹介資料をご覧ください。
3分で理解する、SQLインジェクションとは？
まずSQLインジェクションについておさらいしましょう。SQLインジェクションは、データベースを操作する命令文（SQL文）の組み立て方に不備がある場合に発生する脆弱性です。
攻撃者が書いたSQL文が実行されてしまうと、不正ログインや情報漏えいなどの被害が発生します。
SQLインジェクションの脆弱性があるコードを例に説明します。
SELECT ユーザー氏名 FROM ユーザー情報 WHERE ユーザーID=’user_id’
上記のコードは、ユーザーIDを入力してユーザー氏名を検索するSQL文の例です。user_idの部分に存在しないユーザーIDを入力しても、入力したユーザーIDに紐づくユーザー情報は存在しないため検索できません。
しかし、下記のように文字列を入力するとユーザー情報を検索できてしまいます。
malicious’or’1’=’1
この文字列を入力した結果、ユーザーIDとして「malicious」が登録されていた場合、もしくは1=1であるときにユーザー情報が検索可能です。1=1は常に成り立つので、ユーザーIDが分からない場合でもユーザー情報を検索できてしまいます。
このようにSQLインジェクションは、SQL文の知識がなくても簡単に攻撃できる脆弱性です。機会があれば誰でも攻撃でき、重要な情報を入手できる点において危険といえます。
注意：本章では、SQLインジェクションの理解促進を目的に攻撃手法を解説しています。SQLインジェクションを実践する際には、非公開の個人Webサイトで試しましょう。公開済みのWebサイトや他者のWebサイトに対して実施すると、不正アクセス禁止法に触れる可能性があります。
SQLインジェクションの被害事例
SQLインジェクションの被害が甚大になるのは個人情報や決済情報などの重要なデータをデータベースで取り扱うサイトであり、ECサイトに多くみられます。
ここでは、SQLインジェクションで実際に発生した3つの被害事例を紹介します。
クレジットカード情報が7千件以上流出
インテリア商材を扱うECサイトでクレジットカード情報が流出した事例です。データベースには顧客の名簿だけでなく、クレジットカード情報も保存されていましたが、データベースの暗号化やアクセス権限の設定など、必要な対策が取られていませんでした。
その結果、海外から1,500回以上に及ぶSQLインジェクション攻撃を受け、顧客のクレジットカード情報が流出しました。実際にクレジットカードを不正利用されたケースも報告されています。
対策を怠ったことにより、ECサイトを構築した会社は委託元に対して約2,000万円の損害賠償を支払うよう命じられました。脆弱性を放置すると、金銭的被害だけでなく訴訟沙汰に発展することが分かる事例です。
クレジットカード情報の保持・非保持について
※2023年3月14日改定の クレジットカード・セキュリティガイドライン【4.0 版】では、「加盟店は、カード情報を保持しない非保持化(非保持と同等/相当を含む)、又はカード情報を保持する場合は PCI DSS に準拠する。」と定められています。
参考：経済産業省「クレジットカード・セキュリティガイドライン【4.0版】が改訂されました」
2万件以上のメール情報が流出
アウトドア用品を取り扱うECサイトで、顧客・取引先のメールアドレスが2万件以上流出した事例です。幸いにも氏名やクレジットカードなどの情報は流出しませんでしたが、原因調査のためECサイトを長期閉鎖せざるを得ないなど経済的損失が大きい上に、顧客の信頼損失を招いてしまう事例です。
会員IDとパスワードが10万件以上流出
マーケティング会社のWebサイトから10万件以上の会員IDとパスワードが流出した事例です。情報漏洩の疑いがあるとの報告を受けて調査した結果、SQLインジェクション攻撃による不正アクセスが発覚しました。
クレジットカード情報やコンサルティングで得た機密情報は攻撃を受けたWebサイトではなく、切り離された別システムで保管・管理されていたため、流出しませんでした。
カード情報非保持の場合も、決済など重要な処理を実行する際に、ユーザー本人による操作か確認ができていないと、Webアプリケーションの脆弱性による攻撃を受け、カード情報をとられてしまうリスクがあります。 脆弱性対策を行い、万が一の時に備えておくことをおすすめします。
データベースへのアクセスポイントは絶えず攻撃の対象となっている
データベースとやり取りしている場所すべてが攻撃対象になり得るのがインジェクション攻撃の怖さです。ログイン画面はしっかり対策をしていても、それ以外の画面は狙われにくいとの考えから対策を十分に行っておらず、そこが狙われてしまう場合もあります。
NoSQLもまた、SQLと違うのでインジェクション攻撃は受けないだろうとの考えから対策が十分に行われていない場合があるかもしれません。しかし、実際にはNoSQLへのインジェクション攻撃は存在します。
「NoSQLでもインジェクション攻撃は成立する｜仕組みと対策を解説」では、NoSQLデータベースもSQLのようにインジェクション攻撃を受けてしまう理由、対策方法を解説しています。NoSQLを活用されている方は、ご一読いただく事をおすすめします。
SQLインジェクションに効果的な対策
前述の事例でも紹介したようにSQLインジェクション対策をしなければ、企業の信頼失墜や金銭的被害に繋がります。経済産業省も2006年にSQLインジェクション対策を徹底するよう呼びかけているので、しっかり対策を練りましょう。
ここでは、SQLインジェクションに有効な対策を根本的な対策と補完的な対策に分けて紹介します。
根本的な対策：エスケープ処理
エスケープ処理とは、特別な機能を持つ文字を別の文字列に変える処理のことです。SQL文を入力しても単なる文字列と見なされるため、SQLインジェクションを無効化できます。
エスケープ処理する際には、バインド変数の利用が有効です。
バインドとはSQL文にある変数を「命令」ではなく「値」として処理する手法です。バインド関数を用いて、特殊機能を持つ文字列を単なる文字列として処理すれば、SQLインジェクションは成立しません。
補完的な対策：アクセス制御や暗号化
セキュリティ対策をさらに強化したい場合は根本的な対策を実施したうえで、以下を実行するとよいでしょう。
1. データベースへのアクセス権は最小限にする
万が一SQLインジェクション攻撃を受けても被害を最小限に抑えるために、データベースの権限範囲は適切に設定しましょう。
例えば管理者権限のような強い権限によるアクセスが許可されていると、データベースの中のすべてのデータが漏えいしてしまう危険性があります。最小限のテーブルへの参照権限しか付与していなければ、データを書き換えられないためデータの改ざんは発生せず、情報漏えいの被害は最小限に抑えられます。
2. データベースを暗号化する
データベースを暗号化すれば悪用されるリスクを減らせます。暗号化には、テーブル全体を暗号化する方法とデータ毎に暗号化する方法の2つのパターンがあります。
2-1 テーブル全体を暗号化
メリットは対象テーブルのデータを全て暗号化できることです。暗号もテーブル単位で統一できるため、効率的かつ網羅的な暗号化が可能です。
デメリットはデータを復号化するための復号鍵が盗難された場合、テーブルのデータが丸ごと漏えいしてしまうことです。そのため復号鍵の漏えいが発生しないよう、セキュリティ対策を講じる必要があります。
2-2 データ毎の暗号化
テーブルではなく、格納したデータを個別に暗号化するのも有効です。顧客データベースを例に挙げると、メールアドレスやクレジットカードなど各データ毎に暗号鍵を設定します。
メリットは、データ毎にユーザーのアクセスをコントロールできる点です。例えば社員の個人データを暗号化する際、部署や役職に応じて復号鍵を付与できます。ユーザーによってアクセスできるデータを制限できるため、より強固なセキュリティを築けます。
| 暗号化するデータ | 復号鍵が使えるユーザーの例 |
|---|---|
| 氏名 | 全社員 |
| 住所 | 総務部 |
| 基本給 | 人事部 |
| 賞罰記録 | 管理職 |
デメリットはテーブル全体を暗号化する場合と同じく、復号鍵の漏えい対策が必要となる点です。
3. エラーメッセージの情報は最小限に抑える
SQLインジェクションでは、わざと間違ったSQL文を入力して、アプリケーションから返されてきたメッセージをヒントに脆弱性を狙う攻撃方法もあります。
メッセージにエラーの詳細が載ると弱点を解析されやすくなるので、反映する情報は最小限にしましょう。原因を特定しづらくするために、メッセージを抽象化するのもおすすめです。
4. WAFを導入する
WAFとはWebアプリへの攻撃を防ぐファイアウォールで、下記のような機能があります。
- 通信の監視と不正アクセスの排除
- 不正アクセス・攻撃の履歴を取得
- URLとIPアドレスを指定して外部アクセスをコントロール
メリットは、脆弱性の解消が難しい場合でも自社システムを守りやすいことです。なぜならWAFはデータベースに組み込まず、ネットワークに配置して不正アクセスを防ぐからです。
マンションに例えると、自室に不審者が辿り着く前にエントランスのオートロックで侵入を防ぐようなイメージです。仮に自室の鍵が開いていても（SQLインジェクションが可能でも）WAFが警備してくれるため、大事なデータを守れます。
「対策が完了するまでデータベースを守る手段が欲しい」「システムの都合上、SQLインジェクションの解消が難しい」という企業におすすめです。
脆弱性診断の依頼もしくは脆弱性診断ツールの導入を検討する
ここまで4つの対策を紹介しましたが、専門知識が無いと実行が難しいケースもあります。万全の対策をしたつもりでも、脆弱性に気づかないこともあるかもしれません。
自社の対応だけでは不安な場合、専門ベンダーに脆弱性診断の依頼をする、もしくは脆弱性診断ツールの導入を検討しましょう。
経済産業省がECサイトの脆弱性診断を必須要件に
近年のECサイトへのサイバー攻撃による個人情報やクレジットカード情報の流出増加を踏まえ、2023年3月16日に経済産業省が「ECサイト構築・運用セキュリティガイドライン【4.0 版】」を公開しました。
同ガイドラインの「ECサイトの構築時におけるセキュリティ対策要件」には、必須区分として「ECサイトの公開前に脆弱性診断を行い、見つかった脆弱性を対策する」ことが記載されています。
脆弱性診断を行うことで、SQLインジェクションなどの攻撃を受けやすい脆弱な箇所を見つけることができるため、Webサイトを攻撃から守れるようになります。
脆弱性診断については「脆弱性診断（セキュリティ診断）とは｜必要性からやり方まで、すべて解説」に詳しく記載しています。
まとめ｜大切なデータを守るためにもSQLインジェクション対策を
本記事ではSQLインジェクションの概要と被害事例、対策について紹介しました。
- SQLインジェクションの被害はデータの盗難・破壊など多岐に渡る
- エスケープ処理でSQLインジェクションを無効化する
- データベースの暗号化でデータ漏えい時のリスクを低減できる
- 脆弱性の解消が難しい場合はWAFがおすすめ
- 脆弱性診断でWebのセキュリティ対策を万全にする
SQLインジェクションを許してしまうと、データの破壊や漏えいなど深刻なセキュリティ被害を受けます。企業側の過失も認められると信頼を失うでしょう。本記事で紹介した対策方法を参考に、大切なデータを守ってください。
