Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

8,137 views

Published on

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

Published in: Internet

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

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

×