Webアプリのセキュリティ自動検査ツールの弱点
とまぁ、要件に対するチェック方法として、自動検査ツールを使うと言うのは一つの解だと思う。しかし、現状の検査ツール（商用、フリー問わず）で全ての脆弱性が見つけられるわけではない。とはいえ、非常に簡単なボットなどで利用されるような脆弱性はある程度見つけられる。
実際に、検査ツールで見つかった脆弱性を直しておけば、ボット程度であればある程度何とかなるとは思うのだけど。
ツールに頼るだけではアレなので、一般にツールが不得意なケースと言うのを知っておくことは有益だと思う。
例えばA->B->C->Dというページ遷移があり、A->Bのリクエストで入力したデータを元にC->Dで処理を行うとする。A->Bのリクエストに攻撃パターンを入れて送信すると、Dで脆弱性が発生する場合、多くの自動検査ツール（IとHのやParos）では、この用に複数ページ遷移後に発生する脆弱性は発見できない。これは、A->Bで入力されたテストデータでの脆弱性の確認はBだけで行われるためである。
- セッション管理が厳しいアプリのテストは不得意
例えばA->B->C->Dというページ遷移がある場合、多くのツールはB->Cのテストを実施する際、A->Bのリクエストを送信せずに、B->Cのテストリクエストを送信しまくる。セッション管理が厳しい場合、このようなケースは検査できない。
- 多くの自動検査ツールは複数のパラメータを用いた場合に発生する脆弱性は、検出できない
例えば、以下のような出力するアプリがあったとする。
<input type='hidden' name='hoge' value="入力データ1"><input type='hidden' name='huge' value="入力データ2">
ここで、入力データ1、入力データ2はそれぞれHTMLエンコードされていたとしても、「%81」を利用することでXSSが発生するケースがある。多くの検査ツールはパラメータ一つ毎に攻撃パターンを埋め込んで確認している。したがって、このような脆弱性は検出できない
- ユーザ登録機能のようにメールで一度だけ使用できるURLを送信して初めて処理が完了する機能は検査できない
多くの検査ツールではメールを受信する機能は存在していない。このため、この手の、ワンタイムURLとでも言うべき処理の検査は出来ない。
- セッションIDが推測可能かはツールだけではわからない
セッションIDを数多くとり、人が確認することで、傾向があるかどうかはわかるが、現状、グラフなどでわかりやすくは出来るけど、脆弱性があるかどうかは人が判断しないといけない
- 更新系のSQLインジェクションは実はうまく検出できない
コレは、検査パターンの問題によるのだが、SQLのエラーメッセージが出ない限り、データ更新系の検査は今一精度が低い。ブラインドSQLインジェクションの手法で検査することで、エラーメッセージなしに検索系は可能なんだが、更新系の確認は出来ない。
- CSRFは別途確認が必要
CSRFの脆弱性があるかどうかの判断は、正常な手順を行ったときと同じテストレスポンスが帰ってきているかどうかで判断している。したがって、実際に処理が行われたかどうかはわからない。別途メールが飛んだか？データが追加されたかなど確認が必要となる
XSSの脆弱性の場合、レスポンスに送信したJavascriptが実行できる形で埋め込まれているかどうかで確認できるため、ほぼ100%の割合で脆弱性があると判断できる。その他の脆弱性については、テストレスポンスと正常なレスポンスの違いなどで確認しているため、実際に脆弱性があるかどうか再度確認する必要がある。場合によっては、脆弱性が無いとツールが判断しているものに脆弱性があるケースもある。
ってところ？まだまだあるかもしれないけど･･･
だからといってツールが使えないわけではなく、ある程度の振るい分けや、出来てきたアプリに対する受け入れ時の脆弱性チェック程度にはつかえるんではないかな？
