2014年を揺るがしたインジェクション攻撃の手口と対策

この記事をtweetする このエントリーをはてなブックマークに追加

アナタの知識が会社を救う! セキュリティ強化塾

2014年を揺るがしたインジェクション攻撃の手口と対策

2014/12/16


 2014年は春からOpenSSL、Struts2、bashなど、Webアプリケーションの基盤として広く普及している製品に深刻な脆弱性があることが次々に公表され、信頼し切っていたIT基盤が突然崩れ去るような恐怖を味わった人も多かったのではないだろうか。しかしセキュリティ情報に敏感で脆弱性公表に即座に対応できればそれほどの心配はないはず。怖いのは、脆弱性の存在に気づかず製品を利用している場合や、自社で開発したアプリケーションの脆弱性に気づいていない場合だ。脆弱性をつく攻撃を受けて密かに機密情報が流出しているかもしれないのだ。そこで今回は、特にWebアプリケーションの脆弱性を狙う攻撃として今年顕著だったSQLインジェクションとOSコマンドインジェクション、さらにbashやStruts2の脆弱性と対策について紹介し、セキュリティ実装と運用の勘所を考えてみたい。

インジェクション攻撃

SQLインジェクションで11万件のカード情報流出。止まらない脆弱性を狙う攻撃

 昨年5月、ある国内通信機器レンタルサービス業者(A社)がSQLインジェクション攻撃(図1)を受けて個人情報が流出したことを発表した。A社のWebサーバー が攻撃を受け、約11万件のカード名義人名、住所、カード番号、有効期限、セキュリティコードが流出したというのだ。これらの情報を悪用すれば、クレジットカードの不正使用が簡単にできてしまう。

図1 SQLインジェクションを悪用する手口のイメージ
図1 SQLインジェクションを悪用する手口のイメージ
資料提供:IPA

 この漏洩事件に同社が気づいたのは、契約先の決済代行会社からの連絡だった。3月から同社のサービスに申し込んだ顧客のカード情報などが流出していたのだが、連絡を受けるまで同社自身では気付くことができなかった。この事件後、セキュリティ強化や体制見直しが行われ、カード情報は同社が保有せず、外部の決済サービスを利用することとなった。そのビジネスプロセスの見直しとセキュリティ強化対策、顧客への「お詫び」クーポンの提供など、巨額にのぼると見られる出費を余儀なくされたうえ、ブランドイメージも相当に傷ついたことと思われる。
 しかし、実はこの程度の期間の情報漏洩は珍しいことではない。数年単位で少しずつ情報を窃取されていたケース、数年前にSQLインジェクション攻撃によって仕込まれたバックドアを利用して、その後脆弱性がなくなったシステムからある日突然情報が抜き取られたケースも報告されている。つまり、脆弱性の存在とその悪用の実態に無自覚でいると、まったく気づかないままに情報漏洩が進み、ある日突然被害が表面に表れて愕然としてしまうことになるわけだ。
 またSQLインジェクション以外にも、Webアプリケーションの脆弱性はたくさんある。IPAでは2012年発行の「安全なウェブサイトの作り方」において次の9点を挙げている。

(1)SQL インジェクション
(2)OS コマンドインジェクション
(3)パス名パラメータの未チェック/ディレクトリ・トラバーサル
(4)セッション管理の不備
(5)クロスサイトスクリプティング
(6)CSRF(クロスサイト・リクエスト・フォージェリ)
(7)HTTP ヘッダインジェクション
(8)メールヘッダインジェクション
(9)アクセス制御や認可制御の欠落

 これらの脆弱性がWebアプリケーションに潜在することは、現実的にはほとんど避けられない。できるだけ脆弱性を作りこまないような配慮に加えて肝心なのは、その存在が明らかになり次第、脆弱性を迅速に排除するか、脆弱性が被害につながらないような回避策を講じることだ。以下では、代表的なWebアプリケーションの脆弱性を狙う攻撃として、上記(1)(2)を中心に手口のあらましと対策について考えてみよう。


1

Webアプリケーションの脆弱性を狙う2大攻撃

 Webアプリケーションの脆弱性は、セキュリティ実装の不備で生まれている。自社開発アプリケーション以外に商用やオープンソース製品を用いている場合にも、同様の脆弱性が製品に含まれている場合がある。これらのうち、SQLインジェクションは特に深刻な情報漏洩被害を引き起こしており、またOSコマンドインジェクションは最近のインシデント報告が増えているため、特に注意が必要だ。これらについて、以下に攻撃の手口と対策法を紹介していく。

1-1

SQLインジェクション攻撃の手口と対策

 まず深刻な情報漏洩事件をいくつも引き起こしてきたSQLインジェクションの脆弱性を狙う攻撃について説明しよう。冒頭の例が示すように、データベースの奥にある機密データが、周到に構成された攻撃によって盗み出されるケースが後を絶たない。
 図1で見たように、Webアプリケーションはユーザーからの入力をデータベースへの問合せ(SQL文)のパラメータとして組み入れてデータベースに送信するのだが、その入力がアプリケーションが意図していない悪意に基づく文字や構文になっていた場合、本来のデータベース処理ではなく、攻撃者が意図する処理が実行されてしまう。本来ならアプリケーションによってエラーとして排除されるべき入力が、データベースにまで行き着いて、攻撃者が求める処理を行ってしまうわけだ。
 脆弱性があるアプリケーションでこの手口が使われると、データベース内の個人情報などの機密情報が閲覧されてしまうほか、データの改竄や削除、パスワードの変更、時にはシステム停止までが可能になってしまう。またセッションIDの発行や管理の仕組みに不備(脆弱性)がある場合には、セッションIDの横取り(セッションハイジャック/上記の9つの脆弱性のうち(4))が可能になり、正規ユーザーになりすまして、そのユーザーに許可されているすべての操作を行うことも可能だ。またストアドプロシージャなどを利用したOSコマンドの実行(上記の9つの脆弱性のうち(2))により、システムの乗っ取りや他の攻撃の踏み台としての悪用も行われる可能性がある。

【手口の一例】
 SQL文生成の一例(Perlの場合)を挙げてみよう。次のようなSQL文で$idという変数に、ユーザーの入力を当てはめるようにしている場合を考える。
      $q = "SELECT * FROM atable WHERE id='$id'";  
 $idに入るのは文字列を想定しているが、そこに次のような入力を行う。
               ';DELETE FROM atable—  
 すると生成されるSQL文は次のようになる。
              SELECT * FROM atable WHERE id='';DELETE FROM atable--'  
 この文は、データベースの「atable」テーブルのすべてのレコードを削除してしまう。

【対策】
 このような攻撃を防ぐには、ユーザー入力で決まるパラメータ部分を「?」などの記号(プレースホルダ)で示しておき、後に、そこへ実際の値を機械的な処理で割り当てる方法(Prepared Statement)を利用するのが最も安全だ。Javaの場合は次のようになる。 

              PreparedStatement prep = conn.prepareStatement("SELECT *
      FROM employee WHERE name=?");prep.setString(1, "山田");


 プレースホルダへの値の割り当てを「バインド」といい、バインドをデータベースエンジンの側で行う方式を「静的プレースホルダ」、アプリケーション側で値をエスケープ処理してバインドする方式を「動的プレースホルダ」という。静的プレースホルダを用いると原理的にSQLインジェクションの脆弱性がなくなるので、こちらがお薦めだ。ただしデータベースによっては静的プレースホルダが利用できない場合があるのが問題。動的プレースホルダは、バインド処理を実現するライブラリの実装に問題があると脆弱性が生じることがある。またバインド機構そのものが利用できない場合には、文字列連結によるSQL文組み立てが必要になるが、特殊文字のエスケープ処理(「'」→「''」、「\」→「\\」など)が必要で、データベースの種類や設定によってエスケープすべき文字が違うことから漏れや間違いが生じる危険がある。 また文字入力ではなく数値入力をパラメータとする場合でも、PerlやPHPなど変数に型のない言語を使用する場合には、数値以外の文字が入力された場合に文字列として扱ってしまうので、同様の注意が必要だ。 どのような対応をすればよいかはデータベースによって異なるので、IPAの「安全なウェブサイトの作り方」の別冊の形で発行されている「安全なSQLの呼び出し方」などを参考にして、適切な実装を図りたい。

■「ブラインドSQLインジェクション」や情報収集のための攻撃への対策

 なお、一度の攻撃で成果を得ようとするばかりでなく、たくさんの文字列を使った入力を機械的に行って、その応答を調べてテーブル名などを推測し、手間をかけても目的の情報を得る「ブラインドSQLインジェクション」という手口も使われている。これはSQLインジェクション攻撃で意図した情報(検索結果)が表示されない場合に、何度もSQLインジェクション攻撃を仕掛けて少しずつ情報を得る方法だ。この手口も脆弱性を排除しておけば防止できる。
 また単にデータベースの脆弱性を探るために行われる場合もある。その際、攻撃には成功しなくても、攻撃者に返るエラーメッセージからデータベースの種類やエラー原因、エラーとされたSQL文に関する情報を拾い、次の攻撃を組み立てるための情報源とすることがある。これに対しては、データベースに関連するエラーメッセージを相手に表示しないようにする保険的対策も求められるところだ。
 加えて、データベースにアクセスできるアカウントはその権限を最小限に限定することも保険的対策として有効だ。万一1つのアカウントが奪われても、広範囲のデータ閲覧や削除などの不正が行いにくくなる。

■ソフトウェア製品のSQLインジェクション脆弱性

 これまでにセキュリティ管理製品や複数のCMS製品にSQLインジェクションの脆弱性が発見されている。開発やサポートが終了している製品の場合は別の製品への移行、継続している製品の場合はパッチの適用やバージョンアップにより脆弱性をなくすことが必要だ。

セキュリティ情報局にご登録頂いた方限定で「2014年を揺るがしたインジェクション攻撃の手口と対策」の続きがご覧いただけます。

「セキュリティ情報局」とは、週1回のメールとサイト上で、セキュリティの基礎知識や最新情報などの記事をご希望の方にのみご提供する登録制のサービスです。「セキュリティ登龍門50」では、実際に起こったセキュリティに関する被害例やその対策、統計データなどを紹介します。また「セキュリティWatchers」では、最新事情や海外の状況などを専門家がレポートします。


インジェクション攻撃/2014年を揺るがしたインジェクション攻撃の手口と対策」関連の情報を、チョイスしてお届けします

※キーマンズネット内の「インジェクション攻撃」関連情報をランダムに表示しています。

インジェクション攻撃」関連の特集


なくならない脆弱性とそれを狙う攻撃…。どうすればサイバー攻撃を防ぐことができるのか?脆弱性をなくすコ…



クレジットカード情報の漏洩は後を絶ちません。過去の事件を見ながら、カード業界向けセキュリティ標準PC…



年々深刻な被害が報告されるようになっているSQLインジェクション。JSOC、IPAのレポートをもとに…


「WAF」関連の製品

クラウド型(SaaS型)WAFサービス Scutum(スキュータム) 【セキュアスカイ・テクノロジー】 クラウド対応ソフトウェア型WAF InfoCage SiteShell 【NEC】 WAF/DDoS対策サービス TrustShelter/WAF 【NTTソフトウェア】
WAF WAF WAF
顧客情報流出や改ざんの防止、リスト型攻撃などユーザ認証や新たな脅威も適切に防御するクラウド型WAFサービス。導入後に必要な運用もすべてお任せ。 InfoCage SiteShellはWebサーバにインストールするソフトウェア型とWAF専用サーバのネットワーク型のどちらの形態でも導入可能。クラウド環境(IaaS)にも対応。 簡単かつ低コストに、Webサイトセキュリティを強化できる、WAF/DDoS対策サービス。クラウド型WAFなら運用も導入企業側で行わずにすむ。オンプレミス型WAFの提供も可能。

「ネットワークセキュリティ」関連 製品レポート一覧

このページの先頭へ

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この記事に掲載している情報は、掲載日時点のものです。変更となる場合がございますのでご了承下さい。


ページ: 1 | 2 | 3


30007393


IT・IT製品TOP > ネットワークセキュリティ > WAF > WAFのIT特集 > 特集詳細

このページの先頭へ

キーマンズネットとは

ページトップへ