Contenu connexe Similaire à アプリ開発者に大きな影響 2017年版OWASP TOP 10 (20) アプリ開発者に大きな影響 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
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
15. 民法改正とセキュリティガイドライン要求事項
• 瑕疵担保責任の期間変更 ← 開発側のリスク要因増加
• 1年から5年に延長
• 瑕疵に気が付いてから1年以内にメーカーに告知すればOK
• 「攻撃防御」を実装・維持するコストは顧客負担?
• 開発済み製品でセキュアコーディング/セキュアプログラミングの実施を要求されていた場
合、現在でも費用負担要求はかなり厳しい ← 瑕疵修正対応の可能性
• 新規開発で「攻撃防御」実装のコストを顧客が負担しない場合、明確に「顧客の意
志により攻撃防御を実装しないリスクを受容」した証拠を保存
• ISO27000のセキュアプログラミングでは「入力バリデーションの定期的な見直し」を要
求、つまり作った後のメンテナンスが必要。このコストは顧客負担。「攻撃防御」のメンテ
ナンス費用を含む保守契約が結べない場合、別途メンテナンスを発注する旨または
「顧客の意志により攻撃防御をメンテナンスしないリスクを受容」した証拠を保存
2017/6/8©Electronic Service Initiative, Ltd. https://es-i.jp/ 15
16. 損害賠償請求事件 東京地方裁判所判決/
平成23年(ワ)第32060号
• 損害賠償請求事件 東京地方裁判所判決/平成23年(ワ)第3
2060号 平成26年1月23日 ウェブサイトによる商品の受注シ
ステムを利用した顧客のクレジットカード情報が流出した 事故につき、シス
テムの設計、製作、保守等の受託業者の債務不履行に基づく謝罪・問
合せ 等の顧客対応費用、売上損失等の損害賠償責任が肯定された
事例
• 当たり前に対策すべき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
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
未検証の入力
=
入力バリデーション無しの入力
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
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など)
アプリケーション
入力処理
ロジック処理
出力処理
入力処理
ロジック処理
出力処理
モジュール 関数・メソッド
各レイヤーの
信頼境界線
が防御の基本
✓ アプリケーションレベル
の境界防御が特に重要
✓ データは基本的に信頼で
きないが、アプリレベル
で入力バリデーションす
れば、入力としては妥当
性を保証可能