脆弱性診断とは(エンジニア向け)

近年のWebサイト開発に携わるエンジニアの⽅であれば、インターネットに公開することが前提のWebサービスにおいてセキュリティに配慮しなければならないことは、すでにご存知のことかと思います。Webサイトのセキュリティ⾯に配慮するために、積極的に勉強会やセミナーに参加するエンジニアの⽅も増えてきている状況から、実際に業務として、Webサイトの安全⾯の評価のために脆弱性診断を行ったことがある⽅も多いのではないでしょうか?

⼀⽅で、仮想化技術やクラウドサービスの普及、さまざまなフレームワークの台頭、⾼速化のための通信プロトコル拡張やデータベース技術の多様化など、Webサイトを取り巻くテクノロジーは⽇進⽉歩で変化をしています。このような状況にあわせ最新のテクノロジーの習得に加えて、セキュリティ技術までをカバーしようと努⼒されているエンジニアの⽅も多いように感じます。

全ての対応が可能なスーパーエンジニアの⽅も、もちろんおられると思いますが「餅は餅屋」ということわざがあるように、 Webサイトを構築することとセキュリティを担保することは、⼀旦切り離して、後者を専⾨家に任せるという選択を取ることは決して悪いことではありません。

とはいえ任せるにしても、情報過多の現在、ベンダーを選べば良いのか判断に迷うこともあると思います。そのため、ここではセキュリティエンジニア視点から

  • 脆弱性診断とは?
  • ベンダーを選定する際のポイント

といったことを中⼼にお話しさせていただきます。少しでも皆様のお役に⽴てば幸いです。

Webアプリケーション脆弱性診断について

脆弱性診断とは(⾮エンジニア向け)の記事内でも触れましたが、脆弱性診断サービスには⼤きく分けて、プラットフォーム脆弱性診断とWebアプリケーション脆弱性診断の2種類のサービスがあります。ここではWebサイトのリスク評価において⼤きな割合を占めるWebアプリケーション脆弱性診断の⼿法について、技術的について解説していきます。

HTTP

Webサービスにおいて通信のルールとしてHTTP(Hypertext Transfer Protocol)が利⽤されています。インターネットの広がりに併せてHTTPの規格⾃体がバージョンされて、現状では⾼速化のためにパイプライン可能なバージョン2などが主流になりつつありますが、基本的にHTTPはステートレスなプロトコルです。

  • HTTPの概要(verision 1.1まで)
  • HTTPの概要(verision 2)

このため、HTTPでは通信相⼿の状態を記憶することができないため、会員制サイトなどを構築する際には、Webアプリケーション上でユーザーを追跡するセッション管理を実装する必要があります。

  • セッション管理の例(Cookieベースのセッション管理の例)

HTTPリクエストとレスポンス

Webサービスは前述した通り広義でクライアント・サーバーシステムの⼀種となり、Webサイトを遷移する際にバックブランドで以下のようなテキストベースのデータがHTTPベース上の通信でやりとりされています。

  • Webブラウザから送信されるHTTPリクエストの例
  • Webサーバーから応答されるHTTPレスポンスの例

Webアプリケーション脆弱性診断の基本的な原理

様々な実施⽅法がありますが、基本的にWebアプリケーションの脆弱性診断では検査対象の正常な遷移をした際のHTTPリクエストと、その応答であるHTTPレスポンスを軸に検査を実施していきます。

⼤まかに⾔うと正常な遷移で取得したHTTPリクエストをもとに検査対象となり得る箇所(プログラムでアクセスできる⼊⼒値)に検査⽤の⽂字列やデータ(ペイロードと呼びます)を代⼊して送信します。そして、その検査⽤に送信されたHTTPリクエストに対して応答されるHTTPレスポンスの挙動を確認することで脆弱性の有無を判定していきます。

  • 脆弱性診断で送信される検査HTTPリクエストの例

脆弱性診断というと難しいイメージを持つ⽅もおられるかもしれませんが、実際の作業内容のベースは⾄ってシンプルです。そのため、上記の内容だけ聞くと「ソフトウェアで⾃動的にテストすれば良いのでは?」と疑問に感じられる⽅もいるかもしれません。

この疑問に対しては意⾒が別れるところですが、結論として、現状では完全に⾃動化して検査することができないというのが適切な回答になります。

Webアプリケーション脆弱性診断の難点

Webアプリケーションの脆弱性診断は⾃動で行うツール診断と⼿動で行うマニュアル診断があります。前述した通り脆弱性診断作業は単純作業の繰り返しがベースの⼀種のソフトウェアテストであるため

  • ソフトウェアで⾃動化されたツール診断だけ実施すれば良いのでは?
  • 誰がやっても同じような結果が出るのでは?

と考えるのはある意味⾃然なことだと思います。しかし、これは半分正解で半分間違いです。

まず、その理由として挙げられるのは、Webアプリケーションロジックの⾃由度が⾼いことが挙げられます。例えばGoogle検索とYahoo検索を⽐較してみると双⽅は同じ検索サービスです。しかしバックグランドで送受信されるHTTPリクエストや HTTPレスポンスは違います。また、それぞれの検索サイトに実装されている検索ロジックも異なっているため、同じキーワードで検索した場合の検索結果にも差異が⽣じます。

このようにWebアプリケーションでは提供するサービスに併せて、それぞれのサイトで柔軟に仕様を定めることができます。そのためGoogle検索を完璧に⾃動診断できるソフトウェアを開発しようとした場合、まずGoogle検索のロジックを  細に解析する必要が出てきます。その結果、仮にGoogle検索を完璧に⾃動診断できるソフトウェアを構築したとしても、そのツールはGoogle検索のロジックに最適化されているため、同じツールを使ってYahoo検索を完璧に診断することは極めて難しくなります。

なお、このような差分は提供するサービスが異なれば異なるほど⼤きくなります。そのため、ツール診断で実施する場合は、そのWebサイトに合わせた設定を施す必要がありますが、現状、世の中で利⽤されているセキュリティ検査⽤のソフトウェアは汎⽤性が重視されているため、設定を行ったとしても完全に⾃動化することは困難です。

また、Webアプリケーション脆弱性診断をする上で、技術的にセッション管理の壁があります。ユーザーを追跡するセッション管理には明確な規定がないため、それぞれのWebアプリケーションで⾃由に実装することができます。

近年ではCookieベースとトークンベースのいずれかのセッション管理⽅法を⽤いるケースが多いのですが、どちらの⽅法を選んでもセッションIDの名前や⽣成⽅法、有効期限、破棄されるタイミングなどは各サイトで⾃由に決めることができます。このため、明確な決まりのないそれぞれのWebサイトのセッション管理を、ソフトウェアで完全⾃動で判別するのは⾮常に困難です。

なお、仮にセッション管理を無視して診断を実施しても応答データが全てエラーになってしまうため、ツール診断およびマニュアル診断のどちらの⽅法を⽤いる場合でも、ある程度の知識を有したセキュリティエンジニアがセッション管理のロジックを確認する必要があります。

さらに近年のWebサイトではWeb以外のシステムと連携しているケースが多くなっています。代表的なのが会員登録時やお問い合わせ時のメール連携や、2要素認証でのSMS連携やチャレンジレスポンス、あるいは時刻同期式のワンタイムパスワード連携などが挙げられます。

これらは通信プロトコルがHTTPではないことに加えてバックブランドで実行されているケースが多いため、⼀連のシーケンスを全⾃動で診断するには複雑な仕組みが必要になります。そのため、このようなロジックが実装されているWebサイトではツール診断を実施するよりも⼀般ユーザーと同様の操作⽅法を⽤いるマニュアル診断を実施した⽅が効率的に検査することができます。

上記に挙げた内容は一部の例ですが、Webアプリケーションの脆弱性診断は単純作業ながら、基本的なHTTP、HTML、JSON、CSS、サーバーサイド技術、データベースなどの基礎知識に加えて

  • Webアプリケーションロジックの理解
  • セッション管理の⾒極め
  • Web以外のシステムとの連携

など対象サイトを構成する仕様を正しく把握することが必要です。そのため、ツール診断、もしくはマニュアル診断のどちらの手法を選択した場合でも、十分な検査精度を得るためにはある程度の技術練度が必要になってきます。

ベンダーを選定するポイント

ここまではWebアプリケーションの脆弱性診断の実施内容や難点について解説してきましたが、以降は脆弱性診断サービスを利⽤する際に気をつけたいポイントについてご紹介していきます。

費⽤について

まず依頼する側として脆弱性診断に掛かる費⽤については気になるところだと思います。低価格であればそれに越したことはありませんが、気をつけなくてはならないのは「安かろう悪かろう」のサービスを選ばないようにすることです。脆弱性診断は対象Webサイトのリスクを分析して安全性を⾼めることが⽬的ですので、上記のようなサービスを選んでしまっては本末転倒になります。

残念ながら、未だ対象サイトのロジックを分析せずにデフォルト設定のツール診断のみを実施して危険性の⾼い脆弱性を⾒逃した結果をレポートとして納めてくる粗悪なサービスが散⾒されます。仮にWebアプリケーションの99%のロジックが安全であったとしても、残りの1%に重⼤な⽋陥があれば、そこから情報漏洩やサービスの停⽌などのセキュリティインシデントが発⽣します。そのため、Webサイトのセキュリティレベルは、平均値(Average)ではなく最⼩値(Minimum)で評価されます。

上記のような特性を踏まえ、単純に価格が安いという理由だけで脆弱性診断サービスを選ぶことは避け、しっかりと危険性の⾼い脆弱性を検出できる品質の⾼いサービスを選ぶことが望ましいと⾔えます。

品質について

Webアプリケーションのへの攻撃は⼤別すると能動攻撃と受動攻撃に分けられます。能動攻撃はSQLインジェクション攻撃などに代表されるWebアプリケーションにダイレクトに攻撃を加える⽅法です。対して受動攻撃はクロスサイト・スクリプティング攻撃などに代表される⼿法で、罠を仕掛けた上で正規の利⽤者の関与が必要となる⽅法です。

OWASP(Open Web Application Security Project)では、それぞれの攻撃⼿法の対象となる脆弱性を検出する指針として Cheat Sheetを公開していますが、内容を⾒ていただくと分かる通り、このシートにある検出パターンだけでも相当な数があります。

また実際の診断では、このパターンに加えて例えばSQLインジェクションであれば、連携しているデータベースに合わせたシグネチャにカスタマイズする必要があったり、クロスサイト・スクリプティングであれば画⾯構成によってシグネチャをカスタマイズする、あるいは実際のリスクを洗い出すためにWebアプリケーションのロジックに合わせて、どのようなケースで利⽤者が被害に遭うのかを解析するといった作業が必要になります。

このように上記のOWASPのチートシートをもとに診断を行うとしても、対象のWebアプリケーションに応じて微妙に検出パターンを変更したり、対象アプリケーションのロジックを解析しなければならないため、実施者のスキルによって脆弱性が検出ができたり、できなかったりと診断結果が変わってきます。

そのため、例えばベンダーが該当の脆弱性の検出に対応しているといってもどのように対応しているかを⾒極めないといけません。前述した通り脆弱性診断の性質上、技術スキルが個⼈に依存しがちであるため、ベンダーを選定する際には、しっかりと組織的にノウハウを構築している企業かどうかを⾒極めるのがポイントになります。

開⽰していないケースもありますが、脆弱性診断の品質については

  • 診断実績(総数だけではなくリピート率の⾼さなど)
  • 実施体制(複数の担当者、品質保証の責任者の有無など)
  • ベンダー内でのナレッジレベル(情報収集の⽅法や診断⼿法のマニュアル化、エンジニアの育成⽅法など)

なお、実績については総数の多さだけではなくリピート率の⾼さを検討材料にするのが望ましいです。何故ならリピート率の⾼さは顧客満⾜度の⾼さの裏付けと⾔えるからです。

また、診断を実施する際に担当者が複数⼈体制になっている、加えて品質を保証するレベルの⾼いセキュリティエンジニアがレビューアーとして参画するなどといった体制を取るベンダーでは、前述したロジック等の⾒落としを防⽌する体制をとっています。

加えて⽬紛しく変化するサイバー攻撃やそれに伴い発⽣するリスク分析に対応するため、⽇々、情報収集をしっかり行っており、そこで得た情報をナレッジとしてメンバーに共有しているベンダーでは、技術品質が個⼈に依存せずに、どの担当者が実施しても品質の⾼いサービスを提供してくれる(当たり外れがない)ことが予想できます。そのため、この点についても検討の際には押さえておくのが有益と⾔えます。

診断対象について

全てのWebアプリケーションを診断するのが理想ですが、Webアプリケーションの脆弱性診断サービスは対象の多さに⽐例して作業量が増えるため、従量制の価格設定をとるベンダーが⼤半です。そのため、価格との兼ね合いで対象画⾯を絞るケースが多々あります。

そんな時、どの画⾯を優先的に診断対象とすべきか?という選定に苦⼼されている⽅は多いように感じます。対象を選定するための明確な基準がないため、⼀概には⾔えない部分がありますが、基本的には脅威にさらされやすい画⾯を優先的に検査するのが望ましいと⾔えます。

そのため、選定に迷ったら

  • 認証前の画⾯(誰でもアクセスできる)
  • ログイン画⾯(最も攻撃を受けやすい)
  • エラー画⾯(脆弱性が混⼊しやすい)
  • ビジネスロジックに関する画⾯(認可制御などがあった場合のインパクトが⼤きい)
  • 重要情報にアクセスする画⾯(情報漏洩や改変の脅威が⾼い)
  • 決済を伴う画⾯(⾦銭や売買を伴うため脅威に晒されやすい)

などを候補としてみるのが良いと思います。

ただし  意点として、上記の観点だけで選ぼうとすると、例えば⼀般ユーザー向けサイトと管理者向けサイトが分かれているようなWebサービスでは、⼀般ユーザー向けサイトの⽅が優先度が⾼くなる傾向にあるため、管理者向けサイトを診断対象から除外してしまうケースがあります。

このように連携しているWebサイトがある場合、⽚⽅だけを診断対象とするのは望ましいとは⾔えません。このような選定は、近年の攻撃データから鑑みて、例えば⼀般ユーザー向けサイトのお問合せ機能から、管理者向けサイトを経由して攻撃するなど攻撃の複雑化が進んでいる状況を考慮すると、脆弱性をとりこぼしてしまう可能性が⾼いと⾔えます。

上記に挙げた観点はあくまでWebサイト内に存在する画⾯の選定基準ですので、連携するWebサイト(特にECサービスの管理者向けサイトなど)がある場合は、全てのWebサイトを満遍なく対象とすることでシステム全体のリスクが可視化ができます。そのため、仮に各サイトの対象画⾯が減ってしまったとしても関連サイト全てを対象にすることが望ましいと⾔えます。

報告書について

脆弱性診断はただ脆弱性を⾒つけるだけのテストではあまり意味がありません。検出された脆弱性がどれほどの脅威があるかを判断することに価値があると⾔えます。ここまでに脆弱性診断の⽅法論やそれに伴う技術スキルについて解説してきましたが、実は脆弱性診断において最も⾼度なスキルが必要になるのが、この検出した脆弱性のリスクを適切に評価する判断⼒となります。

そのリスク評価が⼤きく反映される報告書については、そのベンダーの技術⽔準が最も反映されます。そのため、選定の際にはサンプルレポートなどを取り寄せて⽐較することをお勧めいたします。

なお、 視するポイントとしては

  • 対象サイトに即したリスク評価がされている
  • 再現⼿順が具体的に例⽰されている
  • 対策⽅法が明確に記述されている
  • ⻑期的な対策指針に⾔及がある

といった内容が挙げられます。

⼀例となりますが、とあるECサービスを提供するWebサイトが診断対象であると仮定します。このWebサイトを診断した結果、SQLインジェクションが検出された場合に

  • SQLインジェクションが検出されたため危険

と単純に検果のみの報告を挙げてくるベンダーもいれば

  • SQLインジェクションの発⽣箇所や挙動、利⽤しているデータベースの種類から考察して、別ユーザーの購⼊情報を改変できる危険性が⾼い
  • 管理機能には顧客の購⼊履歴を閲覧する機能が備わっているため、該当脆弱性を悪⽤することで、管理者ユーザーに対するセカンドオーダー攻撃の可能性がある

など、⼀般論の脆弱性の解説ではなく、具体的に対象Webサイトのロジックに合わせたリスク評価を交えた報告をしてくれるベンダーも存在します。

このような具体的な考察は問題を再現することに対しても有益であり、かつ対策の優先度を決定する際の基準としても⽤いることができるため、上記のような結果報告をしてくれるベンダーを選ぶのが良いでしょう。

また、脆弱性対策についても、個別の問題に対する対策⽅法だけではなく将来的な対策についての⾔及などがあるかもポイントとなります。Webサイトの利⽤者が増えれば、それに⽐例して悪意のある攻撃者が訪問する頻度も上がります。また運⽤⾯を考慮しても、機能追加の発⽣や該当サービスに携わる⼈員の増加や⼊れ替わりなども起こることが予想できます。

常にWebサイトを取り巻く環境が変化する中で、その時々に応じて最適なセキュリティ対策を行うためには、どんな選択肢があるのか?⻑期スパンで考えた場合に、現時点から備えられる事項はあるのか?などの視点をもとに対策⽅法や指針を⽰してくれるベンダーは、⽬先の対処だけではなくトータルで有益な指針を⽰してくれると⾔えます。

⻑⽂となりましたが、脆弱性診断サービスの導⼊を検討される際には、以上のようなポイントを踏まえて選定してもらえれば有益なサービスを選べると思います。ご参考程度になれば幸いです。

まずは手軽にツールで脆弱性診断

本記事では、脆弱性診断の重要性について紹介してきました。

セキュリティベンダーに依頼する脆弱性診断もある一方で低コストで実現できる手法としてツールでの脆弱性診断という選択肢もあります。

ツールでの脆弱性診断を通じてセキュリティレベルを強化したい企業様はぜひ弊社の脆弱性診断サービス「Securify Scan」を活用ください。

無償でのトライアル実施も行っておりますので、
お気軽にお問い合わせください。

Webアプリケーションの
継続的セキュリティを簡単に実現
Securify

ブログ一覧へ戻る

サービスに関するご質問・ご相談など
お気軽にお問い合わせください