著者プロフィール
- 高江洲 勲
- 国立琉球大学工学部情報工学科卒業。同大学院理工学研究科情報工学専攻修了。2004年大手SIerの関連会社に入社し銀行システムの大規模開発・運用業務に従事した後、2009年大手セキュリティ会社に転職しWebアプリケーション診断業務に携わる。そして、2015年11月より情報セキュリティの先進会社にてWebアプリケーション診断・脆弱性調査などの業務に従事している。
はじめに
サイバーセキュリティに対する社会的ニーズの高まりとともに、セキュリティ業界に興味を持つ方、セキュリティ分野に軸足を置きたいと考えている方(アプリケーションエンジニア、サーバーエンジニアなど)が増えてきている様に思います。ただ、自身の業務が多忙であることや、自身の専門分野のスキル向上を常に行う必要があるため、サイバーセキュリティの分野に係る学習時間が確保できない現状や、セキュリティエンジニアを目指すにあたって、どのような仕事内容なのか、何を学習すれば良いのか分からないという現状があるのではないでしょうか。
そこで今回、セキュリティ分野に軸足を置いて活躍したいと考えているエンジニアの方やセキュリティ業界への転職を考えているエンジニアの方々に向けて、本稿を執筆させていただくことになりました。特にシステムエンジニア(以下、SE)の方々の中には、セキュリティ業界およびその業務内容に対する不透明感があり、セキュリティエンジニアへキャリアチェンジするのに二の足を踏む方もいるのではないでしょうか。そんなエンジニアの方に向けてエールを送りたいというのが本稿を執筆する目的です。
今回の執筆では、私が専門としているWebアプリケーションに対するセキュリティ診断業務(以下、Webアプリ診断)について説明いたします。そのため、本稿で想定している読み手としては、システム開発で3年程度の経験があり、セキュリティ業界に興味を持っているSEの方を対象としています。
本稿を通して、SEからセキュリティエンジニアへの転身は可能であること、Webアプリ診断を行うための必須スキル・心構え、Webアプリ診断の内容や魅力が伝われば幸いです。
第1章：Webアプリ診断の業務内容
本章では、Webアプリ診断の業務内容の説明をします。前半ではWebアプリ診断のイメージについて図などを使って解説し、後半では、診断方法には自動診断と手動診断があり、それぞれの特徴について説明します。
Webアプリ診断とは？ — 疑似攻撃のイメージ —
本Webアプリ診断とは、一言で言うと、Webアプリケーションに潜む脆弱性(注1)を見つけ出す行為です。
診断士(注2)と呼ばれるセキュリティエンジニアが、診断対象のWebアプリケーションに対して疑似攻撃を仕掛け、Webアプリケーションの挙動(注3)から脆弱性の有無を判断します。
診断士はWebアプリケーションの内部構造(ソースコード、設定ファイルなど)を一切把握せずに診断を行うため、Webアプリ診断はブラックボックス型のセキュリティテストに位置付けられます。
通常、Webアプリ診断は①インターネット経由で行うことが多いですが、インターネットに公開されていないWebアプリケーションに対しては、②オンサイト(注4)で診断することもあります（図1参照）。
図1 Webアプリ診断の実施イメージ
Webアプリ診断では、1つのパラメータ(注5)に対して100～300種類以上(診断ベンダーによって異なります)の疑似攻撃を試行します。仮にパラメータ数が10,000個の場合、3,000,000回以上の疑似攻撃を行う必要がありますが、これを全て手作業で行うのは現実的ではありません。そこで、セキュリティ診断ではWebアプリケーションスキャナ(以下、スキャナ)をサポートツールとして使用することがあります(注6) 。
図2 疑似攻撃時のHTTPリクエストイメージ
Webアプリ診断の手法 — 自動検査と手動検査 —
Webアプリ診断は、「自動検査」と「手動検査」を併用して実施します。
自動検査とは、スキャナを使用して診断を行う行為です。スキャナにはWebアプリケーションの脆弱性を検査する診断コード(以下、シグネチャ)が複数用意されており、シグネチャに定義した検査パターンを基に、機械的に脆弱性を検出します。予め用意されたシグネチャを使用して機械的に診断が行えるため、短時間で容易に診断を行うことができます。
しかし、シグネチャとしてパターン定義が難しい脆弱性(注8)は検出することができません。また、脆弱性を機械的に検出するため、誤検知が多く発生することがあります。よって、自動検査とはいえ、スキャナの診断結果は必ず診断士が一つずつ確認する必要があります。
一方、手動検査とは、自動検査で判別できない脆弱性を対象とします。WebブラウザからWebアプリケーションに向けて送信されるHTTPリクエスト通信をローカルプロキシツール(クライアントで動作するプロキシ)(注9)で一旦保留にし、診断士がHTTPリクエストを任意の形に改変した上で送信します。そして、それに対するレスポンスを解析し、脆弱性の有無を判別します。
診断士が任意の検査を行うことができるため、自動検査で検出できない脆弱性を検出することができます。しかし、全て手動で行う性質上、診断に多くの時間を要します。また、脆弱性の検出精度は診断士のスキルに依存するため、診断品質の均質化が難しいという課題があります。
このように、自動検査と手動検査には長所・短所があります。よって、双方の特徴を理解し、お互いに短所を補うように手法を組み合わせる必要があります。
なお、実際の診断業務では時間的・費用的な制約があるため、全ての検査パターンを網羅的に試行することは非常に困難です。よって、診断ベンダーは自身の知見を活かし、限られた時間・費用の中で最大限の診断効果が得られるように工夫します。これが診断ベンダーの腕の見せ所となります。
- 自動診断
-
- 短時間、且つ容易に診断可能
- パターン定義が難しい脆弱性は判別することが困難
- 技術者のスキルにあまり依存しない
- CAPTCHAなど、スキャナによるアクセスを防ぐ仕組みが存在するページは診断できない
- 手動診断
-
- 長時間、且つ技術力・経験が必要
- パターン定義の難しい脆弱性も判別可能
- 技術者のスキルに依存する
- 基本的に診断できないページはない
事例紹介 — 社会的影響が大きかったインシデント事例 —
ここでは、ちょっと視点を変えて、実際に発生したWebアプリケーションにまつわるインシデント事例を紹介しながら、Webアプリ診断が如何に重要であるかを説明いたします。
■PlayStation NetworkおよびQriocityのアカウント情報漏洩(2011年4月)
本インシデントについては、ご存知の方も多いのではないでしょうか。本インシデントが大々的にニュースに取り上げられたあと、私がかつて所属していた会社にもWebアプリ診断の依頼件数が急増したことから、本インシデントが社会に与えた影響は大きいと考えています。
本インシデントは、ソニー・コンピュータエンタテインメント(SCE)のゲーム機向けネットワークサービス「PlayStation Network(現PSN)」と音楽配信サービス「Qriocity」に登録されていた機密情報(氏名、住所、Eメールアドレス、生年月日、パスワード、オンラインIDなど)が漏えいした可能性があるというものです。攻撃者が情報を搾取した具体的な手口は明らかになっていませんが、SQLインジェクション(注10)と呼ばれる攻撃が主に使用されたと言われています。
本インシデントでは、約7,700万件の機密情報が漏えいしたと言われており、ソニーは数百万ドルもの損害を被っています。また、ソニーの株価(東証一部)についても、本インシデント後に株価が下落していることから、少なからず本インシデントがソニーの経営に打撃を与えた可能性が高いと考えています。
■エクスコムグローバルのクレジットカード情報漏洩(2013年4月)
本インシデントは、海外旅行者向けのモバイルルータレンタルサービスを提供している同社のWebサイトがSQLインジェクション攻撃を受け、最大で10万9112件のクレジットカード情報やセキュリティコードが漏洩したものです。
本Webサイトでは、サービス利用料の決済をクレジットカードで行う仕組みになっていました。通常、クレジットカード決済は決済代行業者が行うため、サービス提供側のWebサイトのDBにはクレジットカード情報を保存しないことが一般的です。
しかし、本サービスではシステムの設計上、WebサイトのDBにクレジットカード情報を保存しなければならない仕組みになっていました。これにより、約12万件のクレジットカード情報が漏洩するという大きな被害が発生する要因になりました。
上記二つの事例の共通点は、SQLインジェクション攻撃というメジャーな攻撃に対する対策がとられていなかった、または、不十分だったことです。両サービスが、事前にWebアプリ診断を受けていたのかは不明ですが、適切なWebアプリ診断を受けていれば、同攻撃に対する適切な対策を取れていたと思われます。また、後者の事例については、クレジットカード情報という機密情報をWebサイト側で保存する運用についても、事前に見直す機会が与えられていたかもしれません。
このように、インターネットに公開するWebアプリケーションは常に攻撃に晒される危険性と隣り合わせです。有名な大企業だけではなく、中小企業についても攻撃を受けない保証はありません。また、一度攻撃を受けて情報漏洩やサービス停止に追い込まれると、実害に加え、サービスダウンによる機会損失やユーザへの金銭的な賠償、風評被害、更には損害賠償訴訟に発展する可能性もあります。企業経営に与える打撃は大きく、体力のない企業であれば、経営危機に直結してしまいます。
上記のようなリスクを理解していない企業経営者はそう多くはいないと思います。では何故十分なWebアプリ診断を受けないのでしょうか。理由は様々ですが、1つにはWebアプリ診断を受ける予算がないことが挙げられると思います。1回のWebアプリ診断は数十万～数百万程度の費用が掛かりますが(Webアプリケーションの規模によって変動します)、費用対効果が不明で、生産性もないWebアプリ診断に多くの予算をかけられないのが実情だと思われます。
もちろん数万円で実施できるWebアプリ診断もありますが(注11)、診断精度が低かったり、実施できる範囲が限定されていたりなどと、必ずしも効果的に診断ができるという保証はありません。そのため、企業は情報漏洩が発生したときのリスクと診断に要するコストを天秤にかけて、最適なセキュリティガイドラインを検討し、そのための予算を確保すべきと考えています。
なお、日本国内でも情報漏洩の事例が近年急増し、CSIRTを設置するなどセキュリティに予算をかける企業も増えてきたことから、今後より一層Webアプリ診断を実施する企業も増えていくと思われます。
次章では、診断を行うために必要なスキルと、診断士としての心構えについて説明します。
- 注1：脆弱性
- 情報漏洩やなりすまし、サービス提供妨害などに悪用され得る安全上の欠陥。
- 注2：診断士
- 脆弱性診断を行うセキュリティエンジニア。
本稿執筆時点では特に資格は必要ありませんが、技術者・セキュリティベンダのスキルを可視化する事を目的として、脆弱性診断士の資格化に向けた取り組みが始まっています。 - 注3：Webアプリケーションの挙動
- 正常アクセス以外の挙動を確認します。
例えば、レスポンスにDB内の情報が出力されている、サーバ内部エラーが発生している、入力したJavaScriptが無害化されずに出力されている、などは想定外の挙動に該当します。 - 注4：オンサイト
- お客様のオフィスやデータセンターを訪問して診断を行います。
- 注5：パラメータ
- HTTPリクエスト中のGET/POSTパラメータ、リクエストヘッダのこと(図2参照)。
診断ではパラメータ毎に疑似攻撃を仕掛けていきます。 - 注6：スキャナをサポートツールとして使用することがあります
- スキャナとは、パターン定義が可能な疑似攻撃を機械的に実行するツールのこと。
高速に疑似攻撃が行えるため、診断の効率化に大きく貢献します。
スキャナを使用せずに、全て手作業で診断を行う診断ベンダーもあります。
このような診断ベンダーは、他診断ベンダーと差別化を図るために、疑似攻撃の種類を絞り込む代わりに、診断の深度を大きくします。例えば、他診断ベンダーではDBから情報が搾取できる「可能性」を指摘するのに対し、本診断ベンダーは“実際に”DBから「情報を搾取」し、どこまで攻撃が行えるのかを指摘します(注7)。 - 注7：どこまで攻撃が行えるのかを指摘
- ぺネトレーションテストと呼ばれることもあります。
手法や深さの違いなどから、厳密には診断とペネトレーションテストは区別されます。 - 注8：パターン定義が難しい脆弱性
- 人間の知覚を基に判別する脆弱性。
例えば、リクエスト中のパラメータの意味を理解し、その値を書き換えることで他人の情報にアクセスすることや(情報漏洩)、Webアプリケーションに備わっている機能を悪用し、意図しない動作を行わせること(メール送信機能を悪用してスパムメールを送るなど)など。 - 注9：ローカルプロキシツール
- クライアント上のWebブラウザと、Webサーバとの中間に位置するプロキシ。
Webブラウザから送信されるHTTPリクエストやWebサーバから応答されるHTTPレスポンスを一旦保留にすることができます。保留したリクエスト／レスポンスは、本ツール上で自由に改変することができます。 - 注10：SQLインジェクション
- Webアプリケーションが想定しないSQL文を実行させることにより、Webアプリケーションが接続しているデータベース(以下、DB)を不正に操作する攻撃手法です。
DB内情報の改竄、削除、または、取得などの操作を行います。 - 注11：数万円で実施できるWebアプリ診断
- 診断の全てをツールで行う診断です。いわゆるロボット診断と呼ばれます。
ツールがWebアプリケーションのページを巡回しながら診断を行うため、ツールが自動巡回できないページは診断ができません。また、ツールが判別した脆弱性は診断士が精査しないため、結果に誤りが含まれる可能性が高くなります。