アプリ開発者に大きな影響 2017年版OWASP TOP 10

1. Webアプリ開発に大きな影響 2017年版OWASP TOP 10 の変更箇所と対策エレクトロニック・サービス・イニシアチブ

2. コンテンツ • OWASPと「OWASP TOP 10」 • 2017年版 OWASP TOP 10が与える影響 • 新たに追加された「不十分な攻撃防御」脆弱性 • 他のセキュリティ標準とセキュリティガイドライン • セキュアコーディング/セキュアプログラミングガイドラインの現状 • 開発者が取るべき対応 • 既存および新規システム • セキュアなソフトウエアのアーキテクチャー 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 2

3. OWASPとOWASP TOP 10 • OWASPとは－ Open Web Application Security Project • Webシステムのセキュリティ向上を目的とした団体 • 多くのセキュリティ対策、セキュア開発の情報をガイドラインとして公開 • PCI DSS標準でOWASPのガイドラインを参照すべきと明記 • OWASP TOP 10とは • OWASPセキュリティガイドプロジェクトの筆頭プロジェクト • Webアプリケーションで注意すべき脆弱性トップ10とその対策をまとめたガイドライン • Webセキュリティ対策の基礎として広く認知 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 3

4. OWASP TOP 10セキュリティモデル 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 4

5. 2017年版 OWASP TOP 10 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 5

6. 2017年版 OWASP TOP 10 2017年4月RC版、7月～8月に正式版予定 • A7-Insufficient Attack Protection • ほとんどのアプリとAPIは自動・手動両方の攻撃検知・防止・対応する基本的な機能を持っていない。 • 攻撃防御は基本的な入力バリデーションを遥かに越え、自動検知、記録と対応、攻撃の防止さえ行う。 • アプリ所有者は攻撃防止のために迅速にパッチ適用できなければならない。アプリが入力バリデーションを実施していれば、要求事項のほぼ全てが容易に実装可能 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 6

7. 2017年版 OWASP TOP 10 A7 Insufficient Attack Protection （A7 不十分な攻撃防御） • 「攻撃防御は基本的な入力バリデーションを遥かに越え、自動検知、記録と対応、攻撃の防止さえ行う。」 • 上記の文言からセキュアコーディング・セキュアプログラミングの基礎である「入力バリデーションの実装」が行われている事が大前提 • 「入力バリデーション」はセキュアなソフトウェア開発では必須中の必須事項 • セキュアコーディング・セキュアプログラミングでいう「入力バリデーション」とは、 • ホワイトリスト型のバリデーション • 全ての外部入力をバリデーション（つまりアプリレベルのバリデーションは必要最低限のバリデーション） • ブラックリスト型や内部ロジック内でのバリデーションは“漏れ“が発生しやすく、”脆弱”と考えられる 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 7

8. 入力値の種類不正な入力値入力ミスの入力値正しい入力値 2017/5/20© Electronic Service Initiative, Ltd. https://es-i.jp/ 8 入力バリデーションエラーとなる「不正な入力値」は「拒否すべき入力値」仕様上、あり得ない入力 ↓ リスクでしかない入力入力ミスの入力値は「受け入れるべき入力」仕様上、あり得る入力入力値には右の三種類しかない入力バリデーションエラーと入力ミスエラーの違いは明白だが、区別ができていないケースも時々見かけるので注意！仕様が明確な場合、入力の種類は三種類しか存在しないホワイトリスト型チェックは不正な入力値を確実に検知可能

9. ホワイトリストとブラックリストブラックリスト型の検知は構造的に脆弱な方法不正な入力値入力ミスの入力値正しい入力値 2017/5/20© Electronic Service Initiative, Ltd. https://es-i.jp/ 9 ブラックリスト型で完全に不正な入力値を拒否することは困難で検出漏れ（False Negative）が発生する通常の入力仕様は受け入れる入力（ホワイトリスト）を記述するホワイトリスト型妥当な入力（正しい入力値と入力ミスの入力値）のみ受け入れる構造上、妥当な入力のみ許容されるブラックリスト型不正な入力のみ拒否する構造上、不正な入力を許容せざるを得ない（アプリの入力仕様を正確に把握しないWAF で特に顕著）ブラックリスト型で誤検出（False Positive）を発生させた場合、「バリデーションのバグ」となるバグ発生リスクを避けるため、仕組み的に脆弱となる※ WAF – Web Application Firewall

10. A7 Insufficient Attack Protection （A7 不十分な攻撃防御） • 「明らかな攻撃」対策を持たないソフトウェアは脆弱 • 「怪しい入力」対策を持たないソフトウェアは脆弱 • 「明らかな攻撃」 • 入力として無効な値 – 数値パラメーターに文字列など • 「怪しい入力」 • 入力として妥当だが通常は有り得ない値名前に <script>alert(‘XSS’)</script> など • 怪しい入力はブラックリスト型の検知でOK • 明らかな攻撃、怪しい入力を検出・記録・防止することを要求 • IDPS（攻撃検知防止システム）の機能をソフトウェアに実装セキュアなアプリケーションの要件入力バリデーションにより対応 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 10

11. 要求される攻撃防御策 • 攻撃は検知できなければならない • クライアントが生成できない入力（＝不正な入力）をバリデーション（検証）し検出 • 不正な入力には頻繁過ぎる入力、あり得ない入力パターン（例：外部サイトからの POSTリクエスト）なども含む • 攻撃に対応できなければならない • 攻撃を記録、速やかに通知（不正な入力＝攻撃） • リクエスト、IP・IP帯域のブロック。ユーザーのログアウト・凍結 • 迅速なパッチ（修正） • 開発プロセスが1日以内のパッチ適用を実行できない場合、HTTPプロトコル／データフロー分析及びコード実行を防止する仮想パッチを導入する 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 11

12. A7 不十分な攻撃防御開発会社へのインパクト • 入力バリデーションを実装していないWebアプリの場合は問題外 • 入力バリデーション後のセキュリティ処理（記録と防御）を要求 • アプリケーションレベルでセキュアコーディング（ISO27000要求事項）を求められる入力バリデーションを実装していれば比較的容易に対応可能 • 値の形式、大きさ、範囲、個数などをホワイトリスト型バリデーション • OWASP TOP 10では「WAFを利用できる」としているが、これは「アプリケーション所有者向け」の対策 • 基本的には開発会社・開発者向けの記述ではない点に注意 • OWASP TOP 10はPCI DSS標準の要求ガイドラインとして明示されている。PCI DSS 認証を取得するアプリケーション所有者向けの対策も記載 • 基本的にWAFはブラックリスト型に成らざるを得ず、アプリケーションに実装されたホワイトリスト型入力バリデーションに比べ脆弱 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 12

13. A7 不十分な攻撃防御とWAF • WAFは必須ではない • ほとんどの攻撃防御は通常の入力バリデーション＋αで対応可能 • 大多数のアプリで防御が不十分過ぎる為、運営者に最低限の防御策を要求 • 攻撃の検知と防御はアプリで実装した方が精度および管理面で優位 • アプリ開発者はアプリ仕様を知り、その上で対策可能 • 精度が高いホワイトリスト型入力バリデーションが利用可能 • あり得ない入力状態（例：あり得ないPOSTリクエスト）なども分かる • 入力バリデーションで対応できない攻撃も、モデルで対応可能（例：論理的にあり得ない組み合わせのリクエスト） • アプリケーションサーバーはスケールアウトしやすい • WAFで同程度の機能を実装した場合、開発費も運用管理費用も増加 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 13

14. ソフトウェア開発者・開発会社が取るべきアクション • 顧客・上司に「新しい脆弱性タイプ」が追加されたことを告知 • 何もしないことが最も危険（“新しい脆弱性”だが、セキュリティ標準・ガイドの内容も理解する） • 顧客・上司に「現状」を告知 • 「不十分な攻撃防御」がどのような脆弱性か説明 • リスクを十分に理解してもらう • 顧客・上司に「必要なアクション」を提案 • 「アプリケーションの改修」 • 「WAFの導入」（ただし、アプリケーション改修が本筋であることを強調） • WAFによる防御は仕組み的に脆弱であるため、十分な効果を発揮しない場合多い • 「多重のセキュリティ」としての導入価値は十分にある 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 14 顧客・上司の「不十分な攻撃防御」リスク対応に対する選択を文書化して保存することが重要

15. 民法改正とセキュリティガイドライン要求事項 • 瑕疵担保責任の期間変更 ← 開発側のリスク要因増加 • １年から5年に延長 • 瑕疵に気が付いてから1年以内にメーカーに告知すればOK • 「攻撃防御」を実装・維持するコストは顧客負担？ • 開発済み製品でセキュアコーディング/セキュアプログラミングの実施を要求されていた場合、現在でも費用負担要求はかなり厳しい ← 瑕疵修正対応の可能性 • 新規開発で「攻撃防御」実装のコストを顧客が負担しない場合、明確に「顧客の意志により攻撃防御を実装しないリスクを受容」した証拠を保存 • ISO27000のセキュアプログラミングでは「入力バリデーションの定期的な見直し」を要求、つまり作った後のメンテナンスが必要。このコストは顧客負担。「攻撃防御」のメンテナンス費用を含む保守契約が結べない場合、別途メンテナンスを発注する旨または「顧客の意志により攻撃防御をメンテナンスしないリスクを受容」した証拠を保存 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 15

16. 損害賠償請求事件東京地方裁判所判決／平成２３年（ワ）第３２０６０号 • 損害賠償請求事件東京地方裁判所判決／平成２３年（ワ）第３２０６０号平成２６年１月２３日ウェブサイトによる商品の受注システムを利用した顧客のクレジットカード情報が流出した事故につき、システムの設計、製作、保守等の受託業者の債務不履行に基づく謝罪・問合せ等の顧客対応費用、売上損失等の損害賠償責任が肯定された事例 • 当たり前に対策すべきSQLインジェクション攻撃の被害対し、開発費より多い損害賠償請求が認められたケース • OWASP TOP 10などに記載されている対策が実装されていない場合、開発側のリスクは高い 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 16 http://www.softic.or.jp/semi/2014/5_141113/op.pdf

17. セキュリティ標準・ガイドライン • 実はセキュリティ標準・ガイドラインではセキュアコーディング/セキュアプログラミングの第1番目の項目・必要事項として入力バリデーションを挙げている • 防御的プログラミング（1990年代初め～） • ISO 27000 （2000年～、 BS7799からだと1995年から） • CERT（2000年代～） • CWE/SANS （2010年～、 Monster Mitigationが追加） • OWASP TOP 10（2004年、第一位対策は“未検証の入力”） 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 17 セキュアプログラミングと個別の脆弱性対策を分ける為に、次版から削除された。次版の2007年度版では「削除されたからといって、重要な対策でないと誤解しない様に」とする旨の注意事項が記載されている

18. ISO27000/ISMS • 現在のISO27000 2013では以前の版で記載されていた入力バリデーション方法の記述が省略 • ISO 27000/ISMS的にはOWASP TOP 10より前から入力バリデーションを要求 • 具体的なバリデーション方法が省略された経緯はJIS規格（JIS Q 27000:2014）の付録に記載 • セキュアプログラミング／セキュアコーディングが十分普及した為、具体的な記述を削除し、セキュアプログラミング／セキュアコーディングを行うと省略 • セキュアプログラミングで「何が要求されているか？」が問題となる • 以前の版では具体的な入力バリデーション方法が記載されている 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 18 セキュアプログラミングの入力バリデーションを要求

19. CERT TOP 10 Secure Coding Practices • 1. 入力をバリデーションする • 全ての信頼できないデータソースからの入力をバリデーションする。適切な入力バリデーションは非常に多くのソフトウェア脆弱性を排除できる。ほぼ全ての外部データソースに用心が必要である。これらにはコマンドライン引数、ネットワークインターフェース、環境変数やユーザーが制御可能なファイルなどが含まれる。 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 19 参考： https://blog.ohgaki.net/cert-top-10-secure-coding-standard CERT（Computer Emergency ResponseTeam) 米国カーネギーメロン大学に設置されている世界最古のITセキュリティ専門機関入力バリデーションが第一番目の項目

20. CWE/SANS TOP 25 Monster Mitigation • M1 入力制御（入力バリデーション） • Establish and maintain control over all of your inputs. 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 20 参考： https://blog.ohgaki.net/sans-cwe-top-25-monster-mitigation CWE - Common Weakness Enumeration、CVE なども管理するMITRE社（米国政府外郭団体）のプロジェクト。 SANS - コンピューターセキュリティ教育、コンサルティングを行う専門機関。これらは米軍も参照するITセキュリティの権威入力バリデーションが第一番目の項目

21. OWASP Secure Coding Practices – Quick Reference Guide • セキュアコーディング実践チェックリスト • 第一項目入力バリデーション 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 21 参考： https://blog.ohgaki.net/owasp-secure-coding-practices-quick-reference-guide OWASP自身もセキュアコーディングの第一の対策として入力バリデーションを位置づけている。入力バリデーションが第一番目の項目

22. 実はOWASP TOP 10も • 2004年版（最初のOWASP TOP 10） • A1 2004 Unvalidated Input （バリデーションされていない入力） • Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application. 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 22 https://www.owasp.org/index.php/Top_10_2004 特定の脆弱性対策というよりセキュアコーディング／セキュアプログラミングであることから2007 年版から削除される。日本では「セキュリティ専門家」を含むガイドライン参照者が大きな誤解をしていた。参考： https://www.slideshare.net/ockeghem/owasp- japan20120327 入力バリデーションが第一番目の項目

23. 2007年版 OWASP TOP 10と入力バリデーション • なぜ我々が幾つかの重要な問題を省略したのか？ • 未検証の入力はどのような開発チームにとっても主要な課題であり、多くのアプリケーションセキュリティ問題の根本的な原因です。我々はWebアプリケーションの機能として集中化された入力バリデーション機構を構築することを強く推奨しています。 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 23 未検証の入力＝入力バリデーション無しの入力

24. 入力バリデーションによくある誤解 • 誤解：入力バリデーションは〇〇脆弱性に対して十分な対策ではない！よってセキュリティ対策としてあまり有効・重要ではない • 出力対策は入力対策とは独立した対策である事を理解していない • リスク対策の基礎である多層防御を理解していない • 入力バリデーションは特定の脆弱性対策ではなく、ソフトウェア全体・全般の安全対策 • 入力バリデーションはソフトウェアの正常動作を保証する対策であることを理解していない ← 出力対策だけでは正常動作の保証は論理的に不可能 • コンピュータサイエンスに基づくセキュリティ専門家は入力対策を第一の対策としている • IPAが2016年まで公開していた「セキュアプログラミング講座」が「入力対策」と「出力対策をあべこべにしていた、入力対策が無い、など基本・基礎が間違っているセキュアプログラミング/セキュアコーディング教育が存在した影響も大きいと思われる 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 24 参考： https://www.slideshare.net/ockeghem/owasp-japan20120327

25. 入力バリデーションによくある誤解 • 誤解：入力バリデーションは脆弱性を隠す対策なので、セキュリティ対策としてよくない対策である • ITセキュリティ対策とはリスク管理である事を理解していない • ISO 27000のRisk Treatment（リスク対応）はRisk Mitigation（リスク緩和）、Risk Elimination（リスク排除）、Risk Prevention（リスク防止）、Risk Reduction（リスク削減）であり、リスク排除（脆弱性排除）のみがITセキュリティ対策ではない • 入力バリデーションにより、未知の脆弱性を含め、多くの脆弱性に対応可能。例えば、 Struts2のContent-Type, Content-Lengthヘッダーによるコード実行も防止可能だった • リスク対策の基礎である多層防御を理解していない • そもそも入力バリデーションによる防御は、防御の一つ。しかも効果的な防御策である • アプリによる入力バリデーションより劣るWAFによる入力対策を「セキュリティ対策として良くない」と論じる人は居ない（はず） • 「セキュリティ会社が“入力バリデーション無しアプリを推奨”しつつWAFを推奨・販売する」ことは、「アンチウィルス会社が“ウィルスを作りながら”アンチウィルスソフトを推奨・販売する」ことに等しい 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 25

26. 入力バリデーション無しのアプリ • セキュリティ問題が発生し、裁判となった場合は「入力バリデーションが実装されていない」と開発側は裁判でかなり不利になると考えられる • アプリケーションレベルでの「入力バリデーションの実装」は四半世紀以上前からソフトウェアセキュリティ対策としてセキュリティ専門家が推奨している • 公的なセキュリティ標準や広く認知されているセキュリティガイドラインでも 10年以上前から「入力バリデーションの実装」が要求されている 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 26 • 「攻撃防御は基本的な入力バリデーションを遥かに越え、自動検知、記録と対応、攻撃の防止さえ行う。」 OWASPTOP 10 A7 不十分な攻撃防御 2017年版 OWASPTOP 10は、入力バリデーション実装は当然の前提とし、その上のセキュリティ対策（IDPS）をWebアプリに要求 ※ IDPS – 侵入検知防止システム

27. 開発者はどう対応すべきか？ • 新規システム開発では必ずアプリレベルの入力バリデーションと攻撃防御を実装する • 公開Webアプリケーションでは必須。非公開Webアプリケーションの場合、仕様として「脆弱な仕様」が認められていることを保証 • 仮想パッチとして入力バリデーションが利用できるように実装する 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 27 アプリの99%は「攻撃防御」に必要な「入力バリデーション」を実装していない「赤信号、みんなで渡れば怖くない」状態となっている

28. 開発者はどう対応すべきか？ • 既存システムの場合、可能な限り入力バリデーションと攻撃防御を実装する • 理想的にはアプリケーションに「ホワイトリスト型」の入力バリデーションを実装することが望ましい。入力バリデーションが実装されている場合、攻撃防御の実装は容易 • IPAの旧「セキュアプログラミング講座」が一般的なセキュアプログラミングで第一の対策である入力バリデーションについて記述していなかった点は“言い訳”として利用可能。“セキュリティ専門家”と言われる人であってもセキュアプログラミングを無視する意見・主張が多くあったことも “言い訳”として利用可能 • OWASP TOP 10では「WAFを利用することができる」としている。短期に対応する必要がある場合、WAFも選択肢にできる • WAFによる攻撃防御は構造的にアプリケーションによる攻撃防御に比べ脆弱になるか、 WAFで同等な攻撃防御を実装した場合のコストは高くなる（WAFはより低いレイヤーのHTTPやSSLプロトコル、Webサーバーレベルの問題に対応できる点がメリット） • より脆弱な対応になる事を利害関係者に周知させ、リスク保有者を文書化する 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 28

29. 入力処理出力セキュリティ対策とコンテクスト • 入力処理 • データのコンテクストでバリデーション • 出力処理 • 出力のコンテクストで、エスケープ、安全なAPI、バリデーション（ホワイトリスト） ©Electronic Service Initiative, Ltd. https://es-i.jp/ 29 ✓ HTML：コンテンツ、URI、JavaScript 文字列など ✓ SQL：引数、識別子、SQL語句、拡張機能（正規表現、XML、JSON） ✓ LDAP、XPath、コマンド、etc ✓ それぞれのHTTPヘッダー ✓ 金額、高さ、幅などの数値 ✓ 名前、住所、コメントなどの文字列 ✓ 電話、郵便番号などの定型文字列 ✓ 都道府県、年代などの分類・集合入力処理では “データのコンテクスト“が重要 ✓ できる限り“最終出力”に近い場所でセキュリティ処理を行う ✓ “最終出力”に近い場所の方が “コンテクスト”が明確 2017/6/8 ✓ アプリケーションの入力バリデーション（ホワイトリスト型）が最も重要 ✓ 重要なモジュール/関数は縦深（多層）防御入力元出力先信頼境界線出力処理では ”出力のコンテクスト”が重要

30. ソフトウェアの構造とセキュリティ 2017/6/8 30 PC 電話 IoT サービス DB OS ファイルサービス入力・出力入力・出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力入力処理出力信頼境界線信頼境界線処理これらの内部処理は追加・削除・変更が発生。いつ新たな問題が追加・発見されるかわからないそもそも入力・処理・出力の実装が「危険」であり、それが仕様のモノも内部に多数存在するソフトウエアの外のモノは全て信頼できない「最低限」でも全ての外部入力・出力の安全対策は必須基本的にデータは信頼できない！未検証のモジュール・APIも信頼できない！ ©Electronic Service Initiative, Ltd. https://es-i.jp/ ゼロトラスト！

31. • 基本アーキテクチャ – アプリケーション、モジュール、関数・メソッド、粒度に関わらず共通セキュアなソフトウェアアーキテクチャ 2017/6/13(c) Electronic Service Initiative, Ltd. All rights reserved 31 入力（HTML/JavaScript/JSON/データベース/OS/WebAPIなど）入力処理ロジック処理出力処理出力（HTML/JavaScript/JSON/データベース/OS/WebAPIなど）アプリケーション入力処理ロジック処理出力処理入力処理ロジック処理出力処理モジュール関数・メソッド各レイヤーの信頼境界線が防御の基本 ✓ アプリケーションレベルの境界防御が特に重要 ✓ データは基本的に信頼できないが、アプリレベルで入力バリデーションすれば、入力としては妥当性を保証可能

32. エレクトロニック・サービス・イニシアチブではセキュリティ専門家が推奨するソースコード検査、セキュアコーディング、セキュア開発に関するサービス・サポートを行っていますお問い合わせは info@es-i.jp へ 2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 32