O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Webアプリのセキュリティ 20170824

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 20 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Webアプリのセキュリティ 20170824 (20)

Anúncio

Mais recentes (20)

Webアプリのセキュリティ 20170824

  1. 1. 2017.8.24 ikepyon WEBアプリのセキュリティは 何から手を付ければいいのか ?(仮)
  2. 2. 本日の話 2 開発 運用 開発 運用 開発 要件定義 設計 コーディ ング テスト フレームワーク、ライブラリなどのバージョン管理
  3. 3.  開発工程のコーディングまでにアプリ特有の脆弱性は生まれる  要件定義  クレジットカードのセキュリティコードの保存  設計  アクセス権の不備  コーディング  SQLインジェクション  XSS  ディレクトリトラバーサル アプリの脆弱性 3
  4. 4. そもそもアプリの脆弱性とは?  想定外の動作をするバグのうちセキュリティ上の問題を引 き起こすもの  機密性、完全性、可用性を脅かすもの 4
  5. 5. 7 0 3 0 56% 11% 3% 15% 2%2%11% クロスサイト・スクリプティング SQLインジェクション ディレクトリ・トラバーサル DNS情報の設定不備 ファイルの誤った公開 HTTPSの不適切な利用 その他 6 5 3 5 38% 12%7%4%4% 10% 7% 4%3%11% 任意のスクリプト実行 任意のコマンドの実行 任意のコードの実行 任意のファイルへのアクセス データベースの不正操作 情報の漏洩 なりすまし サービス不能 アクセス制限の回避 その他 コーディングバグ どんな脆弱性が多いのか? 届出累計の脆弱性がもたらす影響別割合 Webサイトの届出累計の脆弱性の種類別割合 5 IPA ソフトウェア等の脆弱性関連情報に関する届出状況[2017 年第 2 四半期(4 月~6 月)]より引用 コーディングバグ
  6. 6. WEBアプリの脆弱性  コーディングバグによる脆弱性が最も多い  全体の約7割  脆弱性を減らすにはまずコーディング時点での脆弱性を減 らすことが効果的 6
  7. 7. アプリのセキュリティ対策の難しさ  一定レベル以上の安全性をすべてのコ ードで保つ必要がある  致命的なバグがコードになければよ い  安全なコードを書くこと自体は難し くない  コーディングバグによる脆弱性の 少ない安全なコードを書くには特 別な知識は不要 7
  8. 8. コーディングでの脆弱性を減らすには?  安全なコーディング方法の教育  セキュリティコードレビュー  動的な脆弱性診断 8
  9. 9. 安全なコーディング方法の教育  メリット  脆弱性のあるコードを書きにくくなる  発見された脆弱性を直せる  デメリット  即効性がない  ケアレスミスによる脆弱性を防げない  既に存在するコード、フレームワークなどの脆弱性を対応す ることは難しい 9
  10. 10. セキュリティコードレビュー  メリット コーディングが終われば脆弱性を発見、直すことができるため、 手戻りが少ない 脆弱性のあるコードをピンポイントで発見できる 網羅的に脆弱性を発見できる  デメリット 実施するにはセキュリティの知識、コードを読む能力が必要 コードレビューを実施するには工数がかかる 発見した脆弱性が実際に攻撃に利用できるとは限らない コードレビューを実施していない場合開発フローを変える必要が ある 10
  11. 11. 動的な脆弱性診断  メリット  攻撃可能な脆弱性を発見できる  開発フローに導入しやすい  デメリット  セキュリティの知識が必要  開発の終盤に実施するため、脆弱性が発見された場合の手戻 りが大きい  コードの修正箇所が具体的にわからない 11
  12. 12. 安全なアプリを作るには何からやれば? 1. 教育は必須  これを実施しないと脆弱性の直し方もわからない  場当たり的な対策となり、完全に修正できないことも 2. 動的な脆弱性診断は最も手軽に開発フローに入れられる  結合テストで実施することを考慮するとよい  すべての脆弱性を発見できないことに注意 3. セキュリティコードレビューは可能なら実施  開発者の技術レベルが不十分だと確認すべき点が多く、工数 が大幅にかかる 12
  13. 13. 安全なアプリを作るには?(教育編)  コーディングの基礎をしっかり学び、実践する  適切なバリデーション、適切なエスケープ  なるべく単純化  仕様に問題がなければ、仕様どおりにしか動かないコード を書けばよい  仕様通りにバリデーションを行い、外部への出力を行う 際、適切なエスケープを行うことで脆弱性を減らせる 13
  14. 14. 安全なアプリを作るには?(教育編)  セキュアコーディングは多くの場合にセキュリティを意識 しなくても脆弱性の少ないコードを書くための方法  セキュアコーディングで常に脆弱性をなくせるものでは ない  フレームワーク、ライブラリには安全なアプリを作るため の機能が存在するので、うまく活用する 14
  15. 15. 安全なアプリを作るには?(脆弱性診断編)  診断パターンは脆弱性診断士ガイドラインが使用できる https://www.owasp.org/index.php/Pentester_Skillmap_Projec t_JP  全機能を網羅的に診断を実施する  脆弱性診断を実施していない箇所に脆弱性がある場合も ある 15
  16. 16. 安全なアプリを作るには?(脆弱性診断編)  簡単に発見できる(自動化ツールで発見できる)脆弱性を発見 、修正する  発見することが難しい脆弱性は攻撃者も発見しづらい  発見しづらい脆弱性を見つけることに時間をかけるより、網 羅的に簡単に発見できる脆弱性がないことを確認することが 重要  網羅的に手動で診断を行うことは結構大変なので、自動化ツー ルを活用する  自動化ツールを使用する場合、設定が重要 16
  17. 17. 安全なアプリを作るには?(脆弱性診断編)  脆弱性として使用できなくても脆弱性っぽいものを発見する ことは難しくない  「’」「<」などを全てのパラメーター、Cookieに入れてみ る  単体テスト、結合テストのテストデータにこれらを含む データを入れてテストすることがいいかも?  おかしな動作をするところを修正するだけでも大幅に脆弱 性を減らすことができる 17
  18. 18. 安全なアプリを作るには?(コーディングレビュー編)  入力(ソース)から脆弱性を引き起こす出力(シンク)ま でのデータフローを追う  シンクに問題を起こすデータが渡されるかを確認する シンクの例  SQLを引数とするメソッド・関数  レスポンスに出力するメソッド・関数 など 18
  19. 19. 安全なアプリを作るには?(コーディングレビュー編)  ソースコード診断ツールもあるので利用することも検討?  脆弱性が検出されすぎるので精査が重要  開発者の技術レベルが高いと検出される脆弱性のほとんど は脆弱性ではない  開発者の技術レベルが低いと検出される脆弱性が多すぎ、 精査の工数がかかりすぎる  フレームワークを使用していると脆弱性が検出できない場合 もある 19
  20. 20. まとめ  何はともあれ教育を実施する  次に導入しやすい動的な脆弱性診断を実施する  テストデータをちょっと変えて、「O'reilly」や「Tully's」 にするだけでSQLインジェクションが見つかるかも?  脆弱性の少ないコードが書けるようになったら、工数削減 のためにコードレビューを実施する 20

×