徳丸さんとの議論は終わっている いるので議論することはありません。しかし、 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ というおかしなスライドが目に入ったのでコメントしておきます。今現在で2万近くのビュー回数もあると放っておけません。
”セキュリティ専門家”という肩書を持つ方が非論理的／非科学的な独自のセキュリティ理論を展開されるようでは、誤解してしまった開発者がセキュアでないコードを書いてしまいます。どのように非論理的／非科学的なのか簡単にコメントします。
問題のスライド
問題のスライドはこちらです。
色々あるのですが、特にp27です。
それ（入力バリデーション）が「セキュリティ対策」かどうかは、”どうでもいい”
とセキュリティ専門家としては論外の主張をされています。因みに私もOWASPの考え方に基本的に大賛成です。しかし、徳丸さんとは捉え方が全く異なります。例えば、文書中で”不可知論”（物事の本質は人には理解できないとする考え方）的な文書と明言しているOWASPのSecure Coding Practices – Quick Reference Guideでは”入力バリデーション”は第一番目に記載されています。そしてその第一項目として
- 信頼するシステム全てが入力バリデーションを実施するよう指揮する
（訳注：自分のアプリケーションだけでなく、関連するシステム全てが入力バリデーションを行っていることを確認する。入力バリデーションを行っていないシステムは危険なシステムとして注意する）
信頼する全てのシステムが入力バリデーションを実施するよう指揮する、としています。ソフトウェアが信頼して利用するシステムに入力バリデーションを実施するよう要求しており、当然ですが開発者がまさに開発しているソフトウェアも入力バリデーションをセキュリティ対策として実施すべきということです。
徳丸さん流のセキュリティ対策が体系的／科学的なセキュリティと異る原因
徳丸さんの「セキュリティ対策」の定義では、「セキュリティ対策とは目的で決る」とする非論理的／非科学的な定義なので、グローバルスタンダードの脆弱性対策が変だ、となってしまうのです。
論理的／科学的／体系的なセキュリティ対策の定義では「主目的」が何かなど人の価値観によって左右される主観では決まりません。主目的がセキュリティ対策を定義するなら、人によってセキュリティ対策はバラバラになってしまいます。論理的／科学的な定義では、人の価値観によって変わってしまうような定義にはなりません。
国際的なITセキュリティ標準であるISO27000用語集の定義では、一般に「セキュリティ対策」と呼ばれる用語に対応する用語は「リスク対応」です。
2.71
リスク対応
リスクを変化 (2.61)させる為のプロセス(2.54)ノート 1
リスク対応には以下の項目を含める事ができる:
- リスクを発生させる活動を開始しない、または継続しないことを決断することによりリスクを回避する
- 機会を獲得する為にリスクを選択または増加させる
- リスクの原因を排除する
- 発生の頻度を変える
- 結果を変える
- 他の組織（契約企業やリスクの資金的処理を含む 訳注：保険など）とリスクを共有し
- 見聞のある選択によりリスクを抑える
ノート 2
否定的な結果をもたらす事象のリスク対応は、”リスク緩和策”、”リスク排除策”、”リスク防止策”、”リスク削減策”などと呼ばれる事がある
ノート 3
リスク対応は新しいリスクを生成したり、既存のリスクを変更することができる
リスク対応の定義から一般に”セキュリティ対策”と呼ばれているモノがリスク対応に含まれていることがわかります。
「セキュリティ対策」という用語が直接定義されていない理由は、徳丸さんのように、「主目的がセキュリティ対策を決める」などの独自定義の用語として利用する方が多いので敢えて定義していないのだと考えられます。
ISO27000の定義では「セキュリティ対策の目的」はどうでもよいモノになっています。「セキュリティ対策」とは「リスクを変化させるモノ」がセキュリティ対策です。「リスクを変化させるモノ」と定義することにより、客観的／定量的／定性的な”セキュリティ対策”の定義が可能になります。客観的／定量的／定性的な評価は、ITセキュリティのみでなく、論理的／科学的な考え方をまとめるために欠かせない要素です。
ISO27000の定義では漏れもありません。リスクを増加させるモノもセキュリティ対策として管理します。解りやすい物ではHTTPSがあります。これは通信経路の機密性を保証するためのセキュリティ対策ですが、HTTPSを利用することによってプロトコルや実装の脆弱性や高度な攻撃によって機密性が維持されないリスクが発生します。こういったリスク増加も認識し、対策を考える（リスクの受け入れも含む）のが標準セキュリティです。
”徳丸さん流のセキュリティ”が”標準セキュリティ”と大きく異る原因の１つは”セキュリティ対策”の定義が論理的／科学的でないことにあります。
OWASPが考える入力バリデーション
このスライドではOWASPが考える入力バリデーションを誤解／曲解して伝えています。
“Validationないよ”と強調されていますが、そもそもOWASP TOP 10の2010年度版の冒頭にも
Welcome to the OWASP Top 10 2010! This significant update presents a more concise, risk focused list of the Top 10 Most Critical Web Application Security Risks.
とOWASP TOP 10はトップ10のWebアプリケーションセキュリティリスクに特化したリストだとしています。つまりリスクの高い特定の脆弱性に特化したチェックリストだということです。入力バリデーションは、多数のセキュリティリスク対策／緩和策として機能しますが、特定のリスクに対するセキュリティ対策ではありません。出力のセキュリティ対策は独立した対策と実施しなければなりません。この事はCERT TOP 10 Secure Coding Practicesに分かり易く解説されています。
7. 他のシステムに送信するデータを無害化する
コマンドシェル、リレーショナルデータベースや商用製品コンポーネントなどの複雑なシステムへの渡すデータは全て無害化する。攻撃者はこれらのコンポーネントに対してSQL、コマンドやその他のインジェクション攻撃を用い、本来利用してない機能を実行できることがある。これらは入力バリデーションの問題であるとは限らない。これは複雑なシステム機能の呼び出しがどのコンテクストで呼び出されたか入力バリデーションでは判別できないからである。これらの複雑なシステムを呼び出す側は出力コンテクストを判別できるので、データの無害化はサブシステムを呼び出す前の処理が責任を持つ。
入力バリデーションはソフトウェアが意図通りに動作するよう保証するために行います。セキュリティ問題もバグの一種です。アプリケーションがバグ（脆弱性）なく動作するためにバリデーションを行います。
同じ2010年度版のOWASP TOP 10には以下の記述もあります。
長いので訳しませんが、XSSを防ぐために入力バリデーションしなさい、と書かれています。OWASPのSecure Coding Practices – Quick Reference Guideでは一番最初の第一項目に実施すべき対策として入力バリデーションを挙げているので、セキュリティ対策として入力バリデーションを行いなさい、と書かれているのは当然でしょう。
OWASPでもOWASP TOP 10でも「入力バリデーションがセキュリティ対策である」と考えていることは明らかです。
入力バリデーションが誤解されやすいセキュリティ対策であることも事実です。最初のOWASP TOP 10では「入力バリデーション」が第一位のセキュリティ対策とされていましたが、入力バリデーションだけ行なえば対策できると開発者が誤解してしまったことが削除された理由だと思われます。“入力バリデーション”と”出力時の安全性確保”は独立した対策であることを理解されなかったことが原因だと思われます。入力セキュリティについてはプログラミング原則の１つである防御的プログラミングの考え方に任せた方が良いとの判断だと推測します。
因みに、CWE/SANS TOP 25では個別のリスク対策以外に、怪物的セキュリティ対策の第一位として入力バリデーションを挙げています。先程紹介したCERT TOP 10 Secure Coding Practices、OWASPのSecure Coding Practices – Quick Reference Guideでも入力バリデーションが第一位のセキュリティ対策です。
入力バリデーションの効果
論理的／科学的なセキュリティ対策では、セキュリティ対策の有効性は客観的に定量的／定性的に評価されます。（参考：実は標準の方が簡単で明解 – セキュリティ対策の評価方法）
入力バリデーションの不備による発生するセキュリティ問題はCWE（Common Weakness Enumiration）のCWE-20として定義されています。
徳丸さん自身も「CWE-20範囲広すぎ」と書かれていますが、ここで書かれてないセキュリティ問題も多くあります。
CWE/SANS TOP 25 Monster Mitigations／CERT Top 10 Secure Coding Practices／OWASP Secure Coding Practicesの第一番目のセキュリティ対策として入力バリデーションを挙げているのは広範囲なセキュリティ問題に対して有効かつ効果が高いためです。
徳丸さん流のセキュリティ定義では「効果」ではなく「目的」によってセキュリティ対策か否かが決るので、いくら効果があっても「セキュリティ対策ではない」（以前はこのように言われていました）「セキュリティ対策かどうかは”どうでもいい”」となります。セキュリティ対策の評価は効果によって判断されるべきで、論理的／科学的な標準セキュリティではそうなっています。「入力バリデーションはセキュリティ対策かどうか”どうでもいい”」にはなりません。
インジェクションが不可能な厳格な入力バリデーションだけではほとんどソフトウェアは作れませんが、入力バリデーションだけでインジェクション攻撃がほぼできないソフトウェアも作ることができます。認証サービスのようなソフトウェアは決まりきった入力のみ取り扱うのでインジェクション攻撃が不可能な入力バリデーションで作ることもできます。潜在的に危険な文字を受け入れなければならないソフトウェアでも、文字コード中の制御コードや多くの記号文字を受け入れなくてもよい入力、決まりきった入力も多数あります。厳格に入力バリデーションを行う事により、徳丸さん自身も「CWE-20範囲広すぎ」と認めるように広範囲の脆弱性対策になります。
科学的／論理的な議論では事実と因果関係が重要です。事実や結果を無視する議論は科学的／論理的な議論とは言えません。
セキュリティ対策の基礎概念の欠如
「入力バリデーションはセキュリティ対策かどうか”どうでもいい”」（セキュリティ対策ではない、からは大きな進歩ですがこれも看過できません）と考えてしまう原因は「セキュリティ対策の基本概念」が欠如していることにある、と思われます。
ITセキュリティに限らずセキュリティ対策の基本は「境界防御」と「縦深防御」です。「境界防御」は「信頼境界線」での入力と出力で行います。ソフトウエアのセキュリティ対策における「信頼境界線」を図にすると以下のようになります。
この図には書いてありませんが、ソフトウェアが利用するライブラリやフレームワークも含め、初期状態では「信頼境界線」の外にあります。※
※ 信頼境界線も誤解されやすい概念のようです。昔、Microsoftさんの資料でデータベースが信頼境界線の中に書かれているものを見かけました。確認したローカルコード以外全てが基本的に、常に信頼境界線の外にある、と理解してください。
「境界防御」は
- 入力
- 出力
で行います。入力バリデーションは「万能性」があるから行うのではなく「境界防御」を行うために実施します。境界防御で必須の入力バリデーションを行わずに必要ないリスクを受け入れるのは良い戦略ではありあせん。
ほとんどのセキュリティ対策とは不確定要素（リスク）をできるだけ軽減・排除する為のモノです。リスクを軽減・排除するには、受け入れる可能な入力のみ受け付け、出力する場合に完全に安全化します。セキュア/防御的プログラミングで入力のセキュリティ対策が第一番である理由には複数ありますが、ソフトウェアの基本構造からも第一番の対策である必要があります。
「信頼境界線」「境界防御」「縦深防御」「セキュア/防御的プログラミング」、これらは全てセキュアなソフトウェア開発に必要な基本概念です。これらを理解していたら「入力バリデーションはセキュリティ対策ではない」「入力バリデーションがセキュリティ対策かどうかは”どうでもいい”」などのと理解にはなり得ません。
一々解説すると長くなりすぎるので省略しますが「信頼境界線」「境界防御」「縦深防御」「セキュア/防御的プログラミング」これら、全ては論理的に正しいと証明可能です。
入力バリデーション至上主義？
入力バリデーションが必要だ、一番重要だ、と解説しているMITRE（CWEやCVEを管理している米国の組織）やCERT（米カーネギーメロン大学に設置されたセキュリティ組織）は入力バリデーションだけやっていればよい、などとは一切言っていません。これは私も同じです。上記のセキュリティ対策の基本概念を理解していればこのような主張をすることはあり得ません。
徳丸さんはSQLインジェクション対策ではエスケープは要らない、と主張されており「プリペアードクエリ至上主義」だったと言えますが、MITREもCERTもOWASPも他のセキュリティ対策が必要ないとは一度も主張していないです。
入力バリデーションはセキュアプログラミングにおいて、効果的かつ合理的なセキュリティ対策なので最も重要なセキュリティ対策として挙げているだけです。徳丸さんが「プリペアードクエリの優位性」を主張され、エスケープの必要性を排除していた※のとは全く異なります。
※ 長い議論の末、現在は徳丸さんもSQLインジェクション対策におけるエスケープは必要だとの認識と理解しています。
私が入力バリデーションをセキュリティ対策として実行すべき、と繰り返し紹介しているのは最も効果的なセキュリティ対策の１つであるにも関わらず、徳丸さんのように「セキュリティ対策ではない」「セキュリティ対策かどうかは”どうでもいい”」と主張される方が居るからです。
入力バリデーションをセキュリティ対策として管理すべきであることは、セキュリティマネジメントの観点からも議論の余地はありません。これを書くと長くなりすぎるので省略します。
まとめ
そもそも用語の定義が非論理的/非科学的では議論の対象にもなりません。さらにセキュリティ対策の基本概念も理由も説明もなく、存在しないかのように無視されるようでは話になりません。論理的／科学的によりよい概念があるのであれば、「バリデーション至上主義」という存在しない考え方を基にあれもある、これもある、と意味のない議論をするのではなく、真っ向からこの論理／概念の方が優れているので「入力バリデーションはセキュリティ対策として”どうでもいい”」と主張されるべきです
ソフトウェアで厳格な入力バリデーションが行われて困るのは、攻撃者と一部のセキュリティ業者だけです。適切な入力バリデーションが行われていれば、そもそも一切インジェクション攻撃ができないはずのパラメータは沢山あります。開発者の「ついうっかり」やシステムや利用する「ライブラリ/サブシステムの脆弱性」を突いて攻撃できなくなり困るのは攻撃者やペネトレーションテストやWAF販売を行っているセキュリティ業者であり、ソフトウェアの開発者や利用者は全く困りません。※
※ スライドでは入力バリデーションが脆弱性を隠すので良くない、との主張されているように読めます。これは90年代のFirewallをホワイトリスト／ブラックリストのどちらで構築すべきか？の議論を彷彿させます。今時Firewallをホワイトリストで作ると「脆弱性を隠すので良くない」と主張する方は居ませんが、これと同じ議論です。
セキュリティ対策の概念、セキュア/防御的プログラミングの概念と全く異なる現在の「セキュリティ専門家」徳丸さんの主張は日本のソフトウェアセキュリティに対して極めて有害だと言わざるを得ません。もしプログラミング原則の一つであるセキュア/防御的プログラミングの第一番のセキュリティ対策を「セキュリティ対策かどうかは”どうでもいい”」と主張されるようであれば、論理的/科学的な根拠を持って主張すべきでは？そのためにはまず主観で決まる定義でなく、普遍的な「セキュリティ対策」の定義が必要です。
入力バリデーションに関する議論は10年間もしていました。私もOWASPのSecure Coding Practicesがセキュアコーディングガイドで
- 信頼するシステム全てが入力バリデーションを実施するよう指揮する
とした不可知論文書を書いたOWASPのセキュリティ専門家の気持ちがわかります。気持ちはわかりはしますが、私は日本の開発者には不可知論”だけ”のセキュリティ対策は必要ない、と考えています。日本の開発者は十分に優秀だと信じています。ただ、不可欠な基本概念や考え方を教わる・学ぶ機会が無かっただけだと思っています。
非論理的/非科学的な主張とその背景をまとめておきます。
- 「セキュリティ対策」の定義が主観で決まり、非論理的/非科学的。
- 「入力バリデーションは広範囲の脆弱性に効果がある」と認めながら、”どうでもいい”は非論理的。 入力バリデーションに欠点があるのと指摘は誤解に基く指摘。
- 入力バリデーションが「脆弱性をあいまいにしたり隠す」ので良くないとの主張は非論理的。こういう誤用をする開発者も居るが、そもそも入力と出力のセキュリティ対策は独立したセキュリティ対策。入力バリデーションは「隠す」ためモノではなく、本質的には「フェイルセーフ対策」。また、脆弱性が見えなくなって困るのは攻撃者のみで開発者・利用者は困らない。セキュリティガイド／標準ではこういった表面化しないリスクもコード検査などを通じて対応するよう要求している。
- 「入力バリデーションはセキュリティ対策として”どうでもいい”」は入力時に「不必要なリスクを受け入れることがセキュリティ対策として”どうでもいい”」を意味するので非論理的。
- 境界防御の「入力」「出力」の両方で対策すれば、リスクが低減することは簡単に数学的な証明が可能。「入力バリデーションはセキュリティ対策として”どうでもいい”」は非科学的。
定義から誤っているとどこまで行ってもボタンの掛け違いは直りません。徳丸さん、2014年のPHPカンファレンスでこの考えと変わっていないことは直接確認できています。もし現在の「セキュリティ対策の定義」や「入力バリデーションに対する考え方」が変わっているようならご連絡ください。このエントリの冒頭で過去の主張であった旨の記載をさせて頂きます。少なくとも徳丸さんを知る私の知人は、現在も徳丸さんの考えは変わっていないとの認識です。
Leave a Comment