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