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

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アプリの脆弱性  コーディングバグによる脆弱性が最も多い  全体の約７割  脆弱性を減らすにはまずコーディング時点での脆弱性を減 らすことが効果的 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