ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～

ここが変だよ、 グローバルスタンダードの脆弱性対策 ～入力値の考え方～ 2012年3月27日 徳丸 浩

OWASP Japan 1st Local Chapter Meeting まことにおめでとうございます 2

OWASPと言えば・・・ OWASP TOP 10 3

OWASP TOP 10とは また上野宣か http://www.atmarkit.co.jp/fsecurity/column/ueno/47.html より引用 4

OWASP Top 10 2004 A1: Unvalidated Input A2: Broken Access Control A3: Broken Authentication and Session Management A4: Cross Site Scripting A5: Buffer Overflow A6: Injection Flaws A7: Improper Error Handling A8: Insecure Storage A9: Application Denial of Service A10: Insecure Configuration Management https://www.owasp.org/index.php/Top_10_2004 参照 5

PCI DSSでも 6.5 すべての Webアプリケーションは「Open Web Application Security Project」ガイドラインなどの安全なコーディング・ガイドラインに基づい て開発する。コーディングの脆弱性を特定するために、カスタム・アプ リケーション・コードを見直す。次に示すような、ソフトウェア開発プロ セスにおける共通のコーディング脆弱性の防止に努める。 6.5.1 入力データの未検証(Unvalidated input) 6.5.2 アクセス制御の不徹底（例えば、ユーザーIDの悪用） 6.5.3 認証・セッション管理の不徹底（アカウント信用証明とセッション・クッキーの使用） 6.5.4 XSS（cross-site scripting）攻撃 6.5.5 バッファ・オーバーフロー 6.5.6 入力不正（例えば、SQL＝structured query languageインジェクション） 6.5.7 不適切なエラー処理 6.5.8 安全でない保管 6.5.9 サービスの拒否。 6.5.10 信頼できない設定管理 PCI DSS v1.1 日本語訳 https://www.pcisecuritystandards.org/security_standards/documents.php より引用 6

「入力データの未検証」ってなんだ? 7

CWEに聞いてみよう 8

CWEとは 共通脆弱性タイプ一覧CWE（Common Weakness Enumeration）は、ソフトウェアにおけ るセキュリティ上の弱点（脆弱性）の種類を識別するための共通の基準を目指しています。 1999年頃から米国政府の支援を受けた非営利団体のMITREが中心となり仕様策定が行 われ、2006年3月に最初の原案が公開されました。その後、40を超えるベンダーや研究機 関が協力して仕様改善や内容拡充が行われ、2008年9月9日にCWEバージョン1.0が公開 されました。 CWEでは、SQLインジェクション、クロスサイト・スクリプティング、バッファオーバーフロー など、多種多様にわたるソフトウェアの脆弱性を識別するための、脆弱性の種類（脆弱性タ イプ）の一覧を体系化して提供しています。CWEを用いると、ソフトウェア開発者やセキュリ ティ専門家などに次のようなメリットがあります。 1. ソフトウェアのアーキテクチャ、デザイン、コードに内在する脆弱性に関して、共通の言葉 で議論できるようになる。 2. 脆弱性検査ツールなど、ソフトウェアのセキュリティを向上させるための、ツールの標準 の評価尺度として使用できる。 3. 脆弱性の原因を認識し、脆弱性の低減を行い、再発を防止するための共通の基準として 活用できる。 現在、CWEは、NISTのNVD、OWASPのTop Ten Projectや、いくつかのセキュリティベ ンダーなどで実際に活用されています。 http://www.ipa.go.jp/security/vuln/CWE.html より引用 9

http://www.ipa.go.jp/security/vuln/CWE.html より引用 10

http://cwe.mitre.org/data/definitions/20.html より引用 http://jvndb.jvn.jp/ja/cwe/CWE-20.html より引用 11

CWE-20範囲広すぎwww http://www.ipa.go.jp/security/vuln/CWE.html より引用 12

そもそも入力値検証でよいのか? 13

米国の書籍の解説例 14

バリデーション至上主義な説解説例1 ホワイトリストフィルタのルールは、甘過ぎても厳格過ぎても困ります。厳格すぎるパターンは、攻 撃者としては付け入る隙を見つけにくくなるため、アプリケーションのセキュリティという観点からは 容認されます。しかし利便性の観点からは、問題となります。正当なユーザーの実在する電子メー ルアドレスが拒否された場合、そのユーザーはサイトを利用できなくなり、大きな損害を被るおそれ があります。 試行錯誤の末、電子メールアドレスについては、次のようなルールに落ち着きます。 • アドレスの名前部分は英数字を基本とし、オプションとしてハイフンとピリオドも使用できる。ハイ フンまたはピリオドの次には、英数字が続かなければならない • 名前部分の次には、@記号が続かなければならない • @記号の次には、アドレスのドメイン部分が続かなければならない。この部分は、最低でも1つ、 最高で3つのテキストブロックで構成される必要がある。各テキストブロックは、英数字を基本都 市、オプションでハイフンも使用でき、最後がピリオドで終わる。ハイフンの次には英数字が続か なければならない。 • アドレスの最後には.com、.net、.orgなどの有効なトップレベルドメインが、1つだけ置かれなけ ればならない やれやれ、電子メールアドレスのように単純に思えるものでも、ずいぶん複雑なルールとなりました。 【略】 Billy Hoffman、Bryan Sullivan著、GIJOE監訳、渡邉 了介訳「Ajaxセキュリティ」、毎日コミュニケーションズ、2008年、P112より引用 15

バリデーション至上主義な説解説例1 ホワイトリストフィルタのルールは、甘過ぎても厳格過ぎても困ります。厳格すぎるパターンは、攻 撃者としては付け入る隙を見つけにくくなるため、アプリケーションのセキュリティという観点からは 容認されます。しかし利便性の観点からは、問題となります。正当なユーザーの実在する電子メー ルアドレスが拒否された場合、そのユーザーはサイトを利用できなくなり、大きな損害を被るおそれ があります。 試行錯誤の末、電子メールアドレスについては、次のようなルールに落ち着きます。 • アドレスの名前部分は英数字を基本とし、オプションとしてハイフンとピリオドも使用できる。ハイ フンまたはピリオドの次には、英数字が続かなければならない • 名前部分の次には、@記号が続かなければならない • @記号の次には、アドレスのドメイン部分が続かなければならない。この部分は、最低でも1つ、 最高で3つのテキストブロックで構成される必要がある。各テキストブロックは、英数字を基本都 市、オプションでハイフンも使用でき、最後がピリオドで終わる。ハイフンの次には英数字が続か なければならない。 RFC 5322 • アドレスの最後には.com、.net、.orgなどの有効なトップレベルドメインが、1つだけ置かれなけ ればならない 適合 やれやれ、電子メールアドレスのように単純に思えるものでも、ずいぶん複雑なルールとなりました。 【略】 Billy Hoffman、Bryan Sullivan著、GIJOE監訳、渡邉 了介訳「Ajaxセキュリティ」、毎日コミュニケーションズ、2008年、P112より引用 16

バリデーション至上主義な説解説例2 ??? これは無意味 Billy Hoffman、Bryan Sullivan著、GIJOE監訳、渡邉 了介訳「Ajaxセキュリティ」、毎日コミュニケーションズ、2008年、P113より引用 • このような方法では効果が薄いだけではなく、ケースバイケーズで正しい方 法を考えなければならない点が問題 • 脆弱性対策は、もっと機械的に適用できるものでないと実用的でない 17

バリデーションで対応できる脆弱性は? 脆弱性パターン名 クロスサイト・スクリプティング SQLインジェクション（文字列） SQLインジェクション（数値） クロスサイト・リクエストフォージェリ 推測可能なセッションID URL埋め込みのセッションID セッションIDの固定化 オープンリダイレクタ HTTPヘッダ・インジェクション（Cookie） HTTPヘッダ・インジェクション（リダイレクト） メールヘッダ・インジェクション ディレクトリ・トラバーサル OSコマンド・インジェクション ファイルインクルード攻撃 evalインジェクション 対応 △ △ ○ × × × × ○ △ ○ ○ ○ △ ○ △ 凡例 ○：対応可 △：仕様次第 ×：対応不可 18

いったんまとめ • Validationは、米国（および、“グローバルスタンダード”）では セキュリティ施策として極めて重要視されている • Validationを「セキュリティ施策」と見る場合、メリットは、「多く の脆弱性に効き目がある」という「万能性」 • 同じく、デメリットは、「根本的解決でない」こと – 「入力値」に着目すると、「セカンドオーダーSQLインジェクション」の ような本質的でないものにも注意が必要になる – 続きは

いったんまとめ • Validationは、米国（および、“グローバルスタンダード”）では セキュリティ施策として極めて重要視されている • Validationを「セキュリティ施策」と見る場合、メリットは、「多く の脆弱性に効き目がある」という「万能性」 • 同じく、デメリットは、「根本的解決でない」こと – 「入力値」に着目すると、「セカンドオーダーSQLインジェクション」の ような本質的でないものにも注意が必要になる – 続きは また上野宣か http://www.atmarkit.co.jp/fsecurity/column/ueno/42.html より引用 20

いや、待て “アメリカ人”を一括りにするな 21

違う意見の人もいるはず… 22

OWASP Top 10 2007 A1: Cross Site Scripting (XSS) A2: Injection Flaws A3: Malicious File Execution A4: Insecure Direct Object Reference A5: Cross Site Request Forgery (CSRF) A6: Information Leakage and Improper Error Handling A7: Broken Authentication and Session Management A8: Insecure Cryptographic Storage A9: Insecure Communications Validation A10: Failure to Restrict URL Access消えている https://www.owasp.org/index.php/Top_10_2007 参照 23

OWASP Top 10 2010 A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access Validation ないよ A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects and Forwards https://www.owasp.org/index.php/Top_10_2010 参照 24

CWE-20の補足を読むと… http://cwe.mitre.org/data/definitions/20.html より引用 http://jvndb.jvn.jp/ja/cwe/CWE-20.html より引用 25

お前とはうまい酒が飲めそうだ 26

まとめ • OWASP Top 10 2004はかなり変だった – 2007, 2010 はかなり良くなったが、ツッコミどころはアリ • 皆さん、バリデーションはちゃんとしましょうね – それが「セキュリティ対策」かどうかは、“どうでもいい” • バリデーションの“万能性”に惑わされずに、脆弱性対処を淡々 とやりましょう – それが漏れのない近道 • 米国でも似たような意見を持っている人は多いと予想 – 私がまだ知らないだけで…まだ見ぬ同士よ! • 相手が米国人だろうが有名人だろうが、言うべきことは言うぜ – OWASP Japanの存在感を! – 皆でOWASP Japanを盛り上げよう 27

Thank you! 28