SQLインジェクションというサイバー攻撃によって、多くの企業が情報漏えいやサービス停止などを余儀なくされる被害に遭っています。本記事ではSQLインジェクションとはどのようなものかわかりやすく解説し、その特徴や被害事例、対策などを説明します。この記事を読んでSQLインジェクションについて理解して、悪意を持った攻撃者から企業の情報やブランドの価値を守り、安全なサービス運営をしましょう。
目次
SQLインジェクションとは？わかりやすく解説します
SQLインジェクションを簡単に説明すると「サイトやサービスのすきを突いて情報を盗み出したり、サイトの内容を勝手に改ざんする攻撃手法」です。よりわかりやすく例を使って説明します。ここではユーザーがIDとパスワードを入力して閲覧する、有料会員専用のWEBページが存在すると仮定しましょう。
このWEBページでSQLインジェクションを使ってサーバーを不正に操作すると、会員登録をしないでWEBページを閲覧できます。つまり、料金を支払わずに有料会員専用のページを閲覧されてしまいます。料金を払わずに有料会員専用ページが閲覧されると、企業はその不正ユーザーのサービス料金を回収できず大赤字です。
さらに悪質な場合には、SQLインジェクションによって他の既存会員の情報を抜き取ることもあります。この場合、企業は情報流出の責任も問われるため、企業のブランドや社会的信頼に大きな傷がつきます。
どちらのケースも企業のサービス存続を危険に晒す悪質な行為です。
SQLインジェクション攻撃の3つの種類とリスクを説明
SQLインジェクション攻撃には大きく分けて3つの種類があります。それぞれについてリスクと合わせて説明します。
1. エラーベースSQLインジェクション
まずはエラーベースSQLインジェクションです。これはわざと誤った情報をサービス内で入力して、サーバーから返ってくるエラーメッセージの内容からデータベースに存在する脆弱性を調査、分析する手法です。この手法によって直接情報を操作されることはないですが、このSQLインジェクションによって取得した情報を分析されて、別の攻撃を受けるきっかけになる危険性があります。
2. UNION SQLインジェクション
次にUNION SQLインジェクションです。これは「unionコマンド」というSQLで利用されるコマンドを悪用し、データベースから情報を抜き出すため「UNION SQLインジェクション」と呼ばれます。わかりやすく例を使って説明します。ここではユーザーニックネームが登録してあるデータベースをデータベースA、ユーザーの本名が登録してあるデータベースをデータベースBと仮定しました。普通のユーザーがアクセスするのはデータベースA（ニックネームが登録してあるデータベース）ですが、悪意を持って「unionコマンド」を利用することで不正にデータベースB（本名が登録してあるデータベース）にアクセスし情報を取得できます。
UNION SQLインジェクションもデータベースに脆弱性があるときに利用され、本来ユーザーに提供しないはずの情報を盗まれてしまい情報流出する危険性があります。
3. ブラインドSQLインジェクション
最後にブラインドSQLインジェクションです。この攻撃はサーバーのデータベースから直接情報を抜き取るのではなく、データベースを管理する情報（実行しているユーザー名や送信に対する応答時間など）やデータベースの構造（テーブルの構造や名前など）を探る攻撃です。
インバンドSQLとは違い、サーバーの情報が直接攻撃者に盗まれないことからブラインドSQLと呼ばれます。しかし、この攻撃でも最終的にサーバー情報が抜き取られてしまうので、リスクの程度はエラーベースSQLインジェクションやUNION SQLインジェクションと変わりません。
クロスサイトスクリプティングとの違い
SQLインジェクション同様、Webサイト、Webサービスを狙った攻撃にクロスサイトスクリプティングがあります。この攻撃はSQLインジェクションと似ている部分もありますが、攻撃の対象と仕組みが異なります。
攻撃の対象は、SQLインジェクションが企業の情報を狙うもので、クロスサイトスクリプティングが個人の情報を狙うものです。この違いは攻撃の仕組みによって生じます。SQLインジェクションは不正なSQL文でサーバー自体に直接攻撃を仕掛ける手法です。これによって企業情報が流出したり、不正にサーバーを閲覧されたりします。一方でクロスサイトスクリプティングは企業のサーバーに罠をしかけて、これを閲覧した個人のPCやスマホから情報を抜き取り不正に個人情報を利用する手法です。クロスサイトスクリプティングが仕掛けられたサーバーで攻撃を受けた個人は、自分自身の情報を悪用されたり、マルウェアに感染したりする被害に遭います。
SQLインジェクションで受ける被害
ここまでSQLインジェクションとは何か詳しく説明してきましたが、ここからは企業がSQLインジェクションを受けたとき、具体的にどのような被害に遭うか説明します。
情報漏えい
不正に情報を閲覧されることで企業の情報が漏えいします。大規模な情報漏えいの場合、情報を漏えいさせた企業としてマスコミで報道されるだけでなく、政府から行政指導が行われ企業の信頼やブランドに傷がつきます。
データ改ざん
ただ不正に情報を閲覧されるだけではなく、データそのものを改ざんされる可能性があります。SQLインジェクションを利用すればデータベースを全て削除することや、データの書き換えが可能です。
これによって、これまで獲得してきた顧客データを全て消失してしまい、サービスを顧客に提供できなくなる場合も考えられます。
また攻撃者によって意図しない情報（犯罪的なメッセージや卑猥な内容など）が、企業サイトで公開されることにより企業イメージを損なう被害に遭う可能性もあります。
サービス停止
情報を漏えいしたシステムでサービスを継続することは難しいですし、そもそもサービス運営に必要なデータが失われてしまえばサービスを継続することはできません。いずれの場合もサービスを一時的、もしくは恒久的に停止することを余儀なくされる可能性が高いです。
サービス運営にコストがかかっていればサービスを停止している間コストのみがかかることになり、頻繁にサービスが停止する状態ではユーザー離れが発生する恐れもあります。
実際の被害事例
SQLインジェクションを実際に受けた企業はさまざまな対応に迫られます。決済代行企業が半年にわたり攻撃を受け続け、決済情報や企業情報が数十万〜数百万件抜き取られた事例では引責での代表取締役の異動、役員報酬の一部返上、経産省からの行政指導にまで発展しました。別の事例では顧客情報が最大12万件流出し、防衛対策の強化や24時間有人監視の体制を構築するなど、大掛かりな対策を求められました。
これらの事例は下記の記事でで詳しく紹介していますので、ご参照ください。
SQLインジェクションの対策方法
SQLインジェクションに遭うと大きな被害を受けてしまうため、事前に対策を講じておくことが重要です。この章ではSQLインジェクションに対する対策を紹介します。
エスケープ処理
SQLインジェクションに対する根本的な対策としてエスケープ処理があります。エスケープ処理とはプログラミング内で特殊な文字として扱われる文字を普通の文字として処理する方法です。
エスケープ処理を行えば攻撃者の入力に含まれる「’（シングルクオーテーション）」や「；（セミコロン）」が普通の文字として処理されるので、不正な命令文をサーバーで実行しません。
プレースホルダの利用
プレースホルダの利用も根本的なSQLインジェクションへの対策です。ユーザー入力値を直接SQL命令文としてサーバーに送信せず、プレースホルダを経由してサーバーに入力することで不正なSQL文の実行を防げます。
その他の対策方法
エスケープ処理、プレースホルダの利用以外にも入力可能文字への規則設定や、WAFの導入でもSQLインジェクションをある程度対策できます。しかし、WAFなどで水際対策をしても根本的に脆弱性が存在している状態では、WAFを突破されるような巧妙なサイバー攻撃には対応できません。サイバー攻撃に対する基本的な姿勢は、脆弱性をサービス内に存在させないことだと考えましょう。
SQLインジェクション攻撃を受けたときに被害を拡大しないために
万が一攻撃を受けてしまったときのことを想定して、攻撃を受けても被害を拡大しない工夫も必要です。例えば下記のような施策を実施しておくことで被害拡大を防げます。
・常時サーバーログを監視する
・サーバーの権限を適度に分割する
・システムを常に最新の状態に保っておく
これらは直接的に攻撃を受けない対策ではありませんが、被害拡大の防止に役立ちます。SQLインジェクションの対策については下記の記事で詳しく説明していますのでぜひ参考にしてください。
SQLインジェクションは脆弱性を狙ったサイバー攻撃
EGセキュアソリューションズ株式会社の「JP-Secure Labs Report Vol.06」によれば、2020年10月〜2020年12月に大手レンタルサーバー運営会社「ロリポップ！レンタルサーバー」で検知したサイバー攻撃の件数は約9,000万件、うち51％がSQLインジェクションによる攻撃でした。
この攻撃から企業を守るためには脆弱性が存在しないサービス運営を目指して、今ある脆弱性に対応するだけでなく、今後発生する脆弱性に都度対応していく必要があります。
そもそもサイトやサービスの脆弱性は、システムがアップデートするたびに生まれてしまいます。また攻撃者も日々攻撃の手法を開発しているため、過去に脆弱性のなかったサービスでも、そのまま放置していると脆弱性を突かれてしまう可能性が高いです。このリスクを回避するためには、現時点でサービス内に脆弱性が存在しないことを確認し、その後も脆弱性のリスクが発生していないかを定期的に把握しておくことが必要です。
しかし、定期的に脆弱性のリスクを把握することは、セキュリティ担当者が脆弱性の有無を都度確認する必要があるため、手間がかかり現実的ではありません。このように「最新の脆弱性まで常に把握する余裕がない」と悩んでいる方は、ぜひ当社サービス「secuas」をご利用ください。1分程度の簡単な情報を入力するだけで貴社サービスのどこに脆弱性が存在しているのか無料で確認できます。
また一度設定いただければ、毎日最新の脆弱性がないかを確認しますので、脆弱性が見つかり次第対応すれば未然に大きな被害を防ぐことが可能です。日々、膨大な数の攻撃が悪意を持って実行されています。この攻撃から身を守るためにも定期的な脆弱性の診断は必須です。自社では手が回らない、そもそもセキュリティの専任担当がいないなどの場合にはぜひ当社サービス「secuas」の無料脆弱性診断をご検討ください。
