自動診断ツールの危険性

概要

本記事では、自動診断ツールの危険性について解説する。

まず、自動診断ツールとは何かというと、ここでは「Webアプリに対して自動的にXSSやSQLインジェクション等の脆弱性を(ほぼ)自動で検出してくれるツール」と定義する。

無料なもので有名どころはOWASP ZAPが有名だ。

OWASP ZAPはプロキシツールであるが、記録したHTTPリクエストに対して自動的にXSS等の脆弱性を検出する動的スキャン機能が実装されている。

以下の図のように、各脆弱性の有無をツールが自動的に判定してくれる。

また、有料で自動診断専門のツールとしてはAppScanやVEX等が有名だ。これら有料ツールは無料ツールに比べて、さらに高い精度で脆弱性を検出できる。

そしてこれらツール操作は簡単であり、セキュリティに詳しくないエンジニアでも十分に扱える。

では、Webアプリの脆弱性を見つけることは誰にでも簡単なことなのか？自動診断ツールさえあればWebアプリは安全なのか？もちろん、そんなうまい話はない。

自動診断ツールの原理

自動診断ツールの問題点を理解するには、自動診断ツールの原理を理解する必要がある。OWASP ZAP(以下、ZAP)をはじめとした自動診断ツールは、何をもって脆弱性を判定しているのだろうか？

原理は単純である。ZAPもVEXも以下のフローで脆弱性を判定する。

1. ブラウジングにより対象ボタンのリクエストを発生させる
2. プロキシツールであるZAPにそのリクエストを通す
3. ZAPがそのリクエストを記録する
4. 記録後、ZAPがそのリクエストを再送する
5. 再送時にリクエストにXSS等の調査ペイロードを含める
6. そのリクエストに対するレスポンスを分析し、脆弱性の有無を調べる

1~6までのステップを順に実践してみる。

まずブラウジングによりリクエストを発生させる。ここではLoginボタンをクリックする。

発生したログインリクエストをZAPが記録する。

ZAPで自動診断機能を使用する。

自動診断機能が実行され、各脆弱性について調査する。

調査リクエストをみると、元々のパラメーターに調査ペイロードが含まれていることが確認できる。例ではXSSについての調査をしていると思われる。

ここでZAPはそのリクエストのレスポンスを分析している。調査ペイロードに対応した反応がレスポンスに発生した時、その脆弱性があると判定する。例えば先ほどの例だと調査ペイロードがレスポンスに、エスケープされずに載った時、XSSの脆弱性があると判断する。

これが自動診断ツールの基本原理である。ここで注目するべき点は

「リクエストを再送する必要がある」

「そのリクエストに対応したレスポンスしか評価しない」

という点である。

リクエストを再送できない場合

前提条件としてリクエストを記録し、そのリクエストを正常に再送する必要がある。逆に言えば、再送できないリクエストはテストすることができない。

例えば「削除」ボタンなどだ。削除ボタンは何かを削除する機能だが、1度削除してしまえばその資源は多くの場合自動では補充されないだろう。つまりリクエストを再送しても、その資源がないのだから正常な応答は返ってこない。正常な応答が返ってこない場合、当然それは正常な診断にはならない。

工夫によって解決できることもあるが、削除、申請、パスワード変更等、リクエストを記録してそれを再送することが難しい機能というのは多い。

これらは自動診断ツールではテストすることはできない。つまり自動診断ツールだけでそのシステムの安全性を測ることは、この点だけでも難しいことがわかる。

直後のレスポンスに影響が出ない場合

診断ツールは基本的には、そのリクエストに対応したレスポンスしか評価しない。それがどういうことか考えてみよう。

まず、最近のシステムは１ボタンを押した際に複数のリクエストを投げることが多い。例えば「検索」ボタンを押した際に２つのリクエストを順に送信するとする。

1. リクエストA(フォームの入力値などを送信)
2. レスポンスA
3. リクエストB
4. レスポンスB(画面に表示する検索結果のHTML)

この場合、例えば検索時の入力欄に調査ペイロードを含めると、そらはリクエストAに載り、評価はレスポンスAで行われる。もし仮に、リクエストAの影響がレスポンスBにのみ表れたとしても、自動診断ツールはそれを評価しない。つまり、この場合は脆弱性を発見できないことになる。

もう少しわかりやすい例を言えば、画面A→画面B→画面Cと遷移していく機能があったとき、画面A→画面Bの時のリクエストを改ざんすると、画面Ｃに悪影響が出る脆弱性があったとしても、これを見つけることは基本出来ない。

このようにWebアプリの構成によっては適切にツールを適用できても、正確な診断にならないことも多い。

自動診断ツールが検出可能な脆弱性が全ての脆弱性ではない

そもそも論として、自動診断ツールがWebアプリ診断における全ての脆弱性を検出してくれるわけではない。

代表的な例としてはアクセス制御の欠落だろう。アクセス制御の欠落は、リクエストを改ざんすることにより、本来見えてはいけない他人のデータが見えてしまう/更新してしまう脆弱性のことだ。これは2021年のOWASP TOP10にも載るくらい高頻度で発見される脆弱性である。

例えば以下のようなリクエストがあったとする。

http://example.com/data?userid=100

通常このリクエストで自分の日記が開くとする。ここで以下の様にリクエストを改ざんする。

http://example.com/data?userid=200

パラメーターuseridを200に改ざんすることで他人の日記が見える。これがアクセス制御の欠落である。Webアプリはuseridの値のみで誰のデータを開くかを判定していたため、誰がそのリクエストを送信したのかを判定するアクセス制御を行っていなかったのである。

そして自動診断ツールはこの脆弱性を見つけてはくれない。

何故なら「userid」にどのような意味があるかをツールは意味解釈しないし、「他人のデータが見えたのか」「自分の正しいデータが見えたのか」もツールは判定できない。このように表示内容から脆弱性の有無をツールは判定することができない。

今回はアクセス制御の欠落という例を出したが、自動診断ツールが検出できない脆弱性は少なくない数存在する。

まとめ

本記事では自動診断ツールが万能ツールではない点について解説した。

確かに自動診断ツールはWebアプリを見つけることを大きく「補助」してくれる。しかし、それはあくまで補助であり、全ての脆弱性を見つけてくれるわけではない。条件が合わなければツールは適用できないし、そもそも見つけてくれない脆弱性も多い。

もしかすると、どこかのプロジェクトは自動診断ツールを適切に使えばWebアプリのセキュリティは確保できると考えているかもしれない。それは大きな間違えである。私の知る限りでは自動診断ツールは万能ではなく、できないことは多い。

あなたがもし自動診断ツールを使おうと思ったら、何ができて何ができないかを一考してほしい。そのうえで足りない点については別の手段で補完してほしい。まだまだ今の技術では「ボタン一つでセキュリティを確保する」というのは無理なのだ。