Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

9.739 visualizaciones

Publicado el

2015/9/30ささみ発表資料

Publicado en: Internet
  • Inicia sesión para ver los comentarios

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

  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. “ご利用は計画的に”

×