-
Be the first to like this
Upcoming SlideShare
アプリ開発者に大きな影響 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
Be the first to comment