Webアプリケーション脆弱性診断の検査対象をどう絞り込めばよいか

ソニーDNAさんの『入門！基礎からわかる「失敗しないWeb診断業者の選び方」』というブログ記事を読みました。
全体的に穏当な内容で異論はないのですが、興味深い内容なので、屋上屋を架すようですが少し追加して考えてみたいと思います。
私が特に注目したのは以下の箇所です。

2. 検査対象を適切に絞れるか？

セキュリティ対策をくまなく実施できれば安心ですが、それは大きな費用がかかり現実的ではないというケースも多いでしょう。そのため、Web診断では検査対象を適切に絞り込むことが必要です。ログイン画面や課金機能、個人情報管理機能など、セキュリティ対策が特に求められる機能を重点的に検査するには、検査対象を明確にすることが重要になります。

上記の考え方は、脆弱性診断の現場でよく行われているもので、筆者もこれに従うことは多いのですが、検査対象の選定は重要なのでもう少し掘り下げて考えてみたいと思います。

脆弱性と影響範囲の関係

検査対象を検討する上での前提条件として、脆弱性がある箇所（Webページ等）が及ぼす影響範囲がどの程度であるかを考える必要があります。
以前の記事ですが、「SQLインジェクション対策もれの責任を開発会社に問う判決」を書いた際に、私は以下のように書きました。

• Y社は、SQLインジェクションはカード情報とは無関係の箇所にあったので、この脆弱性が原因ではないと主張したが、裁判所はこの主張を退けた

開発会社側は、カード情報と無関係の箇所にSQLインジェクションがあってもカード情報漏洩の原因にならないと主張していましたが、裁判所の判断通り、この主張は間違いです。サイト上のどこにSQLインジェクション脆弱性があっても、その影響はサイト全体に及びます。
このように、脆弱性の中には、影響範囲が広いものと、脆弱性のあるページ等に影響が限定されるものがあります。

以下は、影響範囲が広範囲に及ぶ脆弱性の例です。

• SQLインジェクション
• クロスサイトスクリプティング(XSS)
• ディレクトリトラバーサル
• OSコマンドインジェクション
• HTTPヘッダインジェクション
• セッション固定
• ファイルアップロード機能の脆弱性
• クッキーのセキュア属性不備
• 認証機能の不備

一方、以下は影響範囲が脆弱のある箇所に限定されるものの例です。

• クロスサイトリクエストフォージェリ(CSRF)
• レースコンディション（サイト全体に影響がある場合もある）
• 認可制御の不備

以下は、サイトには直接影響のない脆弱性の例です。

• オープンリダイレクタ（フィッシング経由で間接的に影響はある）
• メールヘッダインジェクション

このように見ていくと、「やっぱりサイト全体を診断しないと駄目なのでは?」という疑問が生じます。もちろん、それが望ましいことは言うまでもなく、元記事でもそのように言及していますが、診断に掛けられる予算が限定されている場合に、ある根拠をもって診断箇所を絞り込むことは可能です。その理由を以下に述べます。

脆弱性毎に、発生しやすい箇所が決まっている

ここまで、脆弱性の影響範囲を検討したので、今度は脆弱性が入り込みやすい場所について検討していくことにしましょう。

SQLインジェクション

SQLインジェクション脆弱性は、SQLアクセスをしている箇所すべてで発生する可能性があります。加えて、その影響がデータベース全体に及ぶことから、可能であればすべての箇所を検査しておくことが望ましいことになります。

クロスサイトスクリプティング(XSS)

クロスサイトスクリプティング脆弱性は、表示処理（HTML等の生成）を行っている箇所すべてで発生する可能性があります。加えて、その影響がWebサイト全体に及ぶことから、可能であればすべての箇所を検査しておくことが望ましいことになります。

ディレクトリトラバーサル

ディレクトリトラバーサル脆弱性は、外部から指定したファイル名によりファイルアクセスしている箇所で発生する可能性があります。GETやPOST等のパラメータがファイル名であるかどうかは外部からは完全には分かりませんが、パラメータ名や値から、ファイル名の可能性が高いと推測できる場合もあります。

OSコマンドインジェクション

OSコマンドインジェクション脆弱性は、外部コマンドを呼び出している箇所で発生する可能性があり、その典型例がメール送信処理の箇所です。また、Web開発に用いる言語が提供していない機能を実現する場合に外部コマンドを呼び出していて、OSコマンドインジェクション脆弱性が発生する場合もあります。

HTTPヘッダインジェクション

HTTPヘッダインジェクション脆弱性は、レスポンスヘッダの出力時に外部由来の文字列が混入しているケースで発生する可能性があり、その典型例がログイン後のリダイレクト処理やクッキー発行処理です。サイトを閲覧すればリダイレクト処理やクッキー発行をどこで行っているかは分かるため、そこだけを診断すればよいことになります。

セッション固定

セッション固定の原因はログイン成功時にセッション固定を防ぐ対策（典型的にはセッションIDの変更）がないことであり、ログイン処理を調べることで診断が可能です。

ファイルアップロード機能の脆弱性

ファイルあっブロード機能の脆弱性としては、スクリプトをアップロードしてサーバー側で実行する、あるいは利用者にJavaScriptを実行させるXSS等があります。いずれもアップロード処理と、それに関連するダウンロード処理を調べることで診断ができます。

クッキーのセキュア属性不備

クッキーのセキュア属性不備は、重要な情報をもつクッキー（セッションIDやトークン等）にセキュア属性がついていることを確認することで診断します。サイト全体を巡回して診断すべきですが、典型的なケースについてはログイン時のクッキー発行で診断することが可能です。

認証機能の不備

認証の不備は主にパスワードの扱いに関するもの、アカウントロック等のセキュリティ機能、ログアウト処理（これはセッション管理の一部として診断する場合もある）などの診断です。最近見かける頻度は少なくなりましたが、こちらで紹介したようなぶっ飛んだものもたまにあります。
診断する箇所は主にログイン機能と、ログアウト機能です。

脆弱性には遍在するものと偏在するものがある

どちらも「ヘンザイ」でややこしい見出しですが、XSSのようにどこにでもある（遍在）脆弱性と、HTTPヘッダインジェクションのように特定の箇所にしかない（偏在）脆弱性があるという意味です。
そして、ログイン処理のようなセキュリティ上重要な処理には、HTTPヘッダインジェクションのような偏在性のある脆弱性がわりあい存在しやすいという性質があります。そして、「認証の不備」のような脆弱性は、当然ながらログイン処理の周辺を診断することになります。
すなわち、抜き取り診断において、ログイン処理などセキュリティ上重要な箇所に絞って診断することの *一応の* 根拠は、以下の通りです。

• ログイン処理など当該機能の脆弱性を診断するのに必要
• 一部の脆弱性はログイン処理の周辺に発生しやすいものがある

しかし、これはあくまで傾向的なものであり、絶対的なものとまでは言えません。

抜き取り検査の診断箇所はどのように選定するのがよいか

脆弱性診断の現場の運用では、抜き取り検査として「ログイン処理などセキュリティ上重要な箇所」に絞って診断することはよく行われますが、それだけだと検査漏れが生じやすくなる可能性もあります。
たとえば、エラー表示のページのように、機能的にもセキュリティ上もあまり重要とは言えないページに、SQLインジェクションやXSSのような脆弱性があった場合、その影響はサイト全体に及び、個人情報など重要な情報が漏洩する原因になりえます。
この可能性をゼロにするには、サイト全体を網羅的に診断するしかありません。しかし、予算の関係で網羅的な診断ができない場合は、重要箇所に加えて、経験上「脆弱性の出やすいところ」を診断対象に加えるとよいでしょう。先に述べたエラー表示のページは、セキュリティ上重要でないがゆえに、一種の油断が生じ、脆弱性が入りやすい傾向があるように思います。
安全なウェブサイトの作り方別冊として公開されている「ウェブ健康診断仕様」には、診断そのものの手法に加えて、抜き取り箇所についても一応の基準が説明されています。

まとめ

脆弱性診断の検査箇所を検討する際の考え方について紹介しました。現場でよく行われる「セキュリティ上重要な箇所のみを診断する」ことについて、一応の根拠はあるものの、それだけで重要な情報が守られるわけではありません。このため、抜き取り検査の検査箇所を工夫することにより、同じコストであってもより精度の高い診断が期待できます。
また、「Web診断業者の選び方」として、診断箇所を絞り込む際のリスクや、現実的な対応等について、適切な助言を与えてくれる業者を選ぶとよいでしょう。