脆弱性検査ツールってどうよ

脆弱性検査ツールってどうよ

1. 1. セキュリティ自動検査ツールって ぶっちゃけどうなのよ？ 2015/9 ssmjp ikepyon
2. 2. アジェンダ • 検査の種類/概要 • 検査ツールの脆弱性検出手法 • 検査ツールの向き不向き
3. 3. 検査の 種類/概要
4. 4. 検査手法 • 動的検査 • ブラックボックステストや、Dynamic Application Security Test（DAST）とも呼ばれることもある • 静的検査 • ホワイトボックステストや、Static Application Security Test（SAST）とも呼ばれることもある
5. 5. 動的検査 • 稼働しているアプリケーションに対して脆弱性検査を実施 • テストリクエストを送信し、そのレスポンスを解析して脆 弱性の有無を判断 • テストリクエストは正常系のリクエストを元に作成する テストリクエスト http://example.com/?param=“><script>alert(1)</script> テストレスポンス
6. 6. 動的検査の特徴 • 脆弱性が存在することを確認、証明できる • 脆弱性のあるページとパラメーターがわかる • 以下のような脆弱性が検出出来る • SQLインジェクション • XSS • セッションフィクセーション • パストラバーサル • コマンドインジェクション • ビジネスロジックの脆弱性 • レースコンディション • バッファオーバーフロー
7. 7. 動的検査の欠点 • ソースコードのどこを直せばいいのかわからない • すべてのコードフローを検査するためにテストケース の洗い出しなど事前準備が必要 • 内部構造に依存する問題（暗号化方法、特定の条件で 発現する脆弱性など）を検出しづらい • 稼働するアプリケーションが必要なため、実施できる 工程がテスト工程以降になってしまい手戻りが大きい
8. 8. 静的検査 • ソースコード、設定ファイルに対して脆弱性検 査を実施 • 要するにソースコードレビューと設定レビュー
9. 9. 静的検査の特徴 • 脆弱性がある可能性を検出する（実際には脆弱性が無い場合もある） • 脆弱性を直すべきコードの場所をピンポイントで指摘できる • コードをすべて確認するため網羅性が高い • コードだけで検査が出来る • 以下のような脆弱性を検出出来る • SQLインジェクション • XSS • パストラバーサル • コマンドインジェクション • 暗号化の問題 • 設定の問題 • バッファオーバーフロー
10. 10. 静的検査の欠点 • 検出された脆弱性が必ずしも悪用可能なわけで は無い（過剰検知が出てくる） • ビジネスロジックに依存するものなど仕様や設 計に依存する脆弱性は検出できない • 動的検査に比べ、セキュリティの知識だけで無 くプログラミングの知識など必要なスキルが多 い
11. 11. 手動検査の問題点 • セキュリティ検査にはさまざまな専門知識が必 要なため、出来る人が限られる • 人手による検査は大きな工数がかかる
12. 12. 自動検査ツールの利点 • 様々な知識を持った専門家で無くてもツールを 使うことで、セキュリティ検査を実施できる • 自動で検査を行うため、作業工数を少なく出 来る • 多くのツールには修正方法の解説もあるため、 セキュリティがわからない開発者でも修正方法 を知ることが出来る
13. 13. 自動検査ツールの問題点 • ツールの判断だけでは過剰検知が発生する • 悪用するために複雑な手順、特殊な攻撃パター ンが必要な脆弱性は検知できない
14. 14. 検査ツールの 脆弱性検出手法
15. 15. 動的検査ツールの検査手順 • 正常系のリクエストを記録 • 必要に応じてセッション維持のためのリクエストを記録 • TOPのURLを設定すると自動でリクエストを生成記録 するツールもある • リクエストだけで無くレスポンスを記録し、テストに使 用するツールもある • テストを送信
16. 16. 動的検査ツール • 文字列検索型 • テストリクエスト送信型 • 正常レスポンス確認型 • 複数のテストリクエスト送信型 • バックコネクション型
17. 17. 文字列検索-テストリクエスト送信型 • テストリクエストを送信し、特定の文字列が存 在すると脆弱性があると判断 • 検出出来る脆弱性は以下の通り • SQLインジェクション • XSS • セッションフィクセーション • パストラバーサル • コマンドインジェクション • バッファオーバーフロー
18. 18. 文字列検索-正常レスポンス確認型 • 最初に記録したレスポンスから特定の文字列を 検索し、その文字列が存在/存在しない場合に 脆弱性があると判断 • 検出出来る脆弱性は以下の通り • CookieにSecure属性が無い • CookieにHttponly属性が無い
19. 19. 複数のテストリクエスト送信型 • 複数のテストリクエストを送信し、期待通りの レスポンスを返すと脆弱性があると判断 • 検出出来る脆弱性は以下の通り • SQLインジェクション
20. 20. 複数のテストリクエスト送信型 • 検査方法例 1. 「<入力データ>’ and ‘a’=‘a」をパラメータに代入して送 信。 2. 「<入力データ>’ and ‘a’=‘b」をパラメータに代入して送 信。 • 脆弱性が存在すると、リクエスト1のレスポンスは正常系の レスポンスと同じ且つ、リクエスト2のレスポンスは正常系 のレスポンスと異なる
21. 21. バックコネクション型 • サーバー側から、接続を要求するようなテスト リクエストを送信し、サーバーからの接続があ れば、脆弱性があると判断 • 検出出来る脆弱性は以下の通り • OSコマンドインジェクション • リモートファイルインクルージョン
22. 22. 静的検査ツールの検査手順 • ソースコード、ライブラリをツールに登録 • ツールによってはコンパイル後のモジュール を登録
23. 23. 静的検査ツール • ソースコードから、コールフローを作成 • 入力から出力のコールフロー中に脆弱性対策が 行われているかを確認。 • 対策が行われていないと脆弱性を検出
24. 24. セキュリティ対策の判断基準 • エスケープ、バリデーションなどのセキュリティ対 策になるメソッド/関数を事前にルールに登録してお き、コールフロー中でそれが使用されているか確認 • データフローを解析し、データが取り得る値を認識 し、出力メソッド/関数へ渡されるデータが脆弱性 を引き起こすか確認 • 問題のあるメソッド/関数を文字列検索
25. 25. 検査ツール の 向き不向き
26. 26. 動的検査ツールの問題点 • ゲーム系のセキュリティ検査には向かない • リクエストはジョブのキューに溜めて、実際の処理が バッチでおこなわれるようなものはバッチ処理に脆弱 性があっても検出出来ない • 同一処理を行える回数に制限があるアプリケーション は検査できない • ツールの設定がアプリに依存して変わるのである程度 のノウハウが必要
27. 27. 静的検査ツールの問題点 • 言語、ライブラリ、フレームワークに統一性が 無いと、カスタムルールが作れないため、精度 の高い検査を行うために手間がかかる • 脆弱性の誤検知が多いため、結果の精査が必 ず必要であり、精査にはセキュリティの知識、 コーディングの知識が必要
28. 28. 動的検査ツールの導入向き不向き • ツールの使い方がうまく展開できないことが多 いので、開発者が多いとうまく使いこなせない 所が多い気がする • QAチームがある場合、QAの一環で実行しても らえると、うまくいくことが多い • 開発を外注している場合、受入テストに使用す るとよかったりする
29. 29. 静的検査ツールの向き不向き • 開発者のレベルが低いと、脆弱性が検出されすぎ、 検出結果の精査も出来ないため、修正出来ない • 自組織で開発していない（開発を外注している） 場合、導入による効果がほぼ無い • 開発者のレベルが高いと、ケアレスミスによる 脆弱性しか検出されなくなるため、テスト前に 脆弱性を修正できるようになる
30. 30. まとめ • 動的検査ツールは、QAや受入テストに向いて いる • 静的検査ツールは開発チーム以外に導入するこ とは向かない • ツールだけですべての脆弱性を検出出来るわけ では無いので過信しない
31. 31. “ご利用は計画的に”