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