---
title: ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～
tags:  #security  
author: [徳丸 浩](https://www.docswell.com/user/ockeghem)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/KYE64GYD7V.jpg?width=480
description: OWASP TOP 10 2004を中心にとして、バリデーション偏向の脆弱性対策にツッコミを入れます。
published: March 27, 12
canonical: https://www.docswell.com/s/ockeghem/ZJQ94K-owasp-japan20120327
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/KYE64GYD7V.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/5GE5QVG874.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/V972P3YV7R.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/5DJY51GQJM.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/2V7NN2G278.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GYJ9R1WDE3.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/5GJ8W4N5ED.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/MLJLN6P37R.jpg)

CWEに聞いてみよう
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/547MX54MEW.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/ZP7RN3WLE9.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/NPJXN4V67X.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/63JKNZQGJD.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/4LE3VDP5J5.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/V8ED8PLYEG.jpg)

米国の書籍の解説例
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/4V7P8N2278.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/L2JVNKDXEQ.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/Z5EGKQYR7L.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/V4JQNKMYJP.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/DK74GPVZJ1.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/PLJ1D93DEG.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/8GJWYQP872.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/W4EZXWK973.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/KY764GQDJV.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/5G75QVR8J4.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/V9J2P3DVJR.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/5DEY512QEM.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/2VJNN282J8.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/GYE9R1KD73.jpg)

Thank you!
28


