Vaddy ミートアップ Vol.7

1. 2017.8.24 ikepyon
WEBアプリのセキュリティは
何から手を付ければいいのか
？(仮)

2. 本日の話
2
開発 運用 開発 運用 開発
要件定義 設計
コーディ
ング
テスト
フレームワーク、ライブラリなどのバージョン管理

3.  開発工程のコーディングまでにアプリ特有の脆弱性は生まれる
 要件定義
 クレジットカードのセキュリティコードの保存
 設計
 アクセス権の不備
 コーディング
 SQLインジェクション
 XSS
 ディレクトリトラバーサル
アプリの脆弱性
3

4. そもそもアプリの脆弱性とは？
 想定外の動作をするバグのうちセキュリティ上の問題を引
き起こすもの
 機密性、完全性、可用性を脅かすもの
4

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

7. アプリのセキュリティ対策の難しさ
 一定レベル以上の安全性をすべてのコ
ードで保つ必要がある
 致命的なバグがコードになければよ
い
 安全なコードを書くこと自体は難し
くない
 コーディングバグによる脆弱性の
少ない安全なコードを書くには特
別な知識は不要
7

8. コーディングでの脆弱性を減らすには？
 安全なコーディング方法の教育
 セキュリティコードレビュー
 動的な脆弱性診断
8

9. 安全なコーディング方法の教育
 メリット
 脆弱性のあるコードを書きにくくなる
 発見された脆弱性を直せる
 デメリット
 即効性がない
 ケアレスミスによる脆弱性を防げない
 既に存在するコード、フレームワークなどの脆弱性を対応す
ることは難しい
9

10. セキュリティコードレビュー
 メリット
コーディングが終われば脆弱性を発見、直すことができるため、
手戻りが少ない
脆弱性のあるコードをピンポイントで発見できる
網羅的に脆弱性を発見できる
 デメリット
実施するにはセキュリティの知識、コードを読む能力が必要
コードレビューを実施するには工数がかかる
発見した脆弱性が実際に攻撃に利用できるとは限らない
コードレビューを実施していない場合開発フローを変える必要が
ある
10

11. 動的な脆弱性診断
 メリット
 攻撃可能な脆弱性を発見できる
 開発フローに導入しやすい
 デメリット
 セキュリティの知識が必要
 開発の終盤に実施するため、脆弱性が発見された場合の手戻
りが大きい
 コードの修正箇所が具体的にわからない
11

12. 安全なアプリを作るには何からやれば？
1. 教育は必須
 これを実施しないと脆弱性の直し方もわからない
 場当たり的な対策となり、完全に修正できないことも
2. 動的な脆弱性診断は最も手軽に開発フローに入れられる
 結合テストで実施することを考慮するとよい
 すべての脆弱性を発見できないことに注意
3. セキュリティコードレビューは可能なら実施
 開発者の技術レベルが不十分だと確認すべき点が多く、工数
が大幅にかかる
12

13. 安全なアプリを作るには？（教育編）
 コーディングの基礎をしっかり学び、実践する
 適切なバリデーション、適切なエスケープ
 なるべく単純化
 仕様に問題がなければ、仕様どおりにしか動かないコード
を書けばよい
 仕様通りにバリデーションを行い、外部への出力を行う
際、適切なエスケープを行うことで脆弱性を減らせる
13

14. 安全なアプリを作るには？（教育編）
 セキュアコーディングは多くの場合にセキュリティを意識
しなくても脆弱性の少ないコードを書くための方法
 セキュアコーディングで常に脆弱性をなくせるものでは
ない
 フレームワーク、ライブラリには安全なアプリを作るため
の機能が存在するので、うまく活用する
14

15. 安全なアプリを作るには？（脆弱性診断編）
 診断パターンは脆弱性診断士ガイドラインが使用できる
https://www.owasp.org/index.php/Pentester_Skillmap_Projec
t_JP
 全機能を網羅的に診断を実施する
 脆弱性診断を実施していない箇所に脆弱性がある場合も
ある
15

16. 安全なアプリを作るには？（脆弱性診断編）
 簡単に発見できる（自動化ツールで発見できる）脆弱性を発見
、修正する
 発見することが難しい脆弱性は攻撃者も発見しづらい
 発見しづらい脆弱性を見つけることに時間をかけるより、網
羅的に簡単に発見できる脆弱性がないことを確認することが
重要
 網羅的に手動で診断を行うことは結構大変なので、自動化ツー
ルを活用する
 自動化ツールを使用する場合、設定が重要
16

17. 安全なアプリを作るには？（脆弱性診断編）
 脆弱性として使用できなくても脆弱性っぽいものを発見する
ことは難しくない
 「’」「＜」などを全てのパラメーター、Cookieに入れてみ
る
 単体テスト、結合テストのテストデータにこれらを含む
データを入れてテストすることがいいかも？
 おかしな動作をするところを修正するだけでも大幅に脆弱
性を減らすことができる
17

18. 安全なアプリを作るには？（コーディングレビュー編）
 入力（ソース）から脆弱性を引き起こす出力（シンク）ま
でのデータフローを追う
 シンクに問題を起こすデータが渡されるかを確認する
シンクの例
 SQLを引数とするメソッド・関数
 レスポンスに出力するメソッド・関数 など
18

19. 安全なアプリを作るには？（コーディングレビュー編）
 ソースコード診断ツールもあるので利用することも検討？
 脆弱性が検出されすぎるので精査が重要
 開発者の技術レベルが高いと検出される脆弱性のほとんど
は脆弱性ではない
 開発者の技術レベルが低いと検出される脆弱性が多すぎ、
精査の工数がかかりすぎる
 フレームワークを使用していると脆弱性が検出できない場合
もある
19

20. まとめ
 何はともあれ教育を実施する
 次に導入しやすい動的な脆弱性診断を実施する
 テストデータをちょっと変えて、「O'reilly」や「Tully's」
にするだけでSQLインジェクションが見つかるかも？
 脆弱性の少ないコードが書けるようになったら、工数削減
のためにコードレビューを実施する
20