以前から気になっては居たのですがJVNのCWE-20の解説ページが出鱈目です。用語の定義が間違っています。もう何年も前から修正されていません。Draftとは言え「セキュアコーディングの第一原則」（IPAは2017年からプログラミング原則としている）入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。
追記：指摘通りに修正されました
このブログ最後に記載の通り、メールにて誤りを指摘していました。最初のJVNへのメールから3週間かかりましたが指摘した通りに修正されました。
標準的な入力バリデーション（入力の妥当性チェック）にはエスケープやフィルタリング、脆弱性を隠すという意味はありません。入力データが形式的に妥当であることを検証するのが入力データバリデーションです。これは70年代のFormal Verificationの頃からの定義です。
近年になって乱用／誤解／拡大解釈により間違った意味で使われている場合があるので注意が必要です。
JVNのCWE-20とMITREのCWE-20の違い
「入力の妥当性チェック」の意味としてJVNでは最初に解説しています。スクリーンショットをそのまま載せます。
最も大きな問題は赤で囲った「名称補足」の部分です。解説の冒頭に「名称補足」があり、「入力の妥当性チェック」の用語の定義であるように記載されています。
「入力の妥当性チェック」という用語は極めて一般的ですが、用語の使い方は様々です。いくつかのケースでは、根本的な脆弱性を曖昧にするためや、関連した複雑な事象を隠すことを目的として使われます。
フィルタリング、正規化やエスケープのような、入力が適切であることを確認する様々な無効化手段をカバーする、総括的な用語としても使用されます。また、もっと狭い文脈において単純に「入力が変化せず、期待される値であることの確認」という意味でも使用されています。
https://jvndb.jvn.jp/ja/cwe/CWE-20.html
これを普通に日本語として読むと、「入力の妥当性チェック」とは
- 根本的な脆弱性を曖昧にたり、複雑な事象を隠す事を目的として使う
- フィルタリング、正規化やエスケープといった無効化手段の総称である
- 狭い意味で「入力が変化せず、期待される値であることの確認」する
という意味であると読めます。これは大間違いです。
※ 原文のCWE-20では「入力の妥当性チェック」の意味の補足として用いているのではなく、乱用・誤用があること事を説明しています。現在のCWE-20には『狭い意味で「入力が変化せず、期待される値であることの確認」する』がCWEが採用する定義であると明記しています。
本家MITREのCWE-20の解説
本家MITREのCWE-20では「名称補足」がどのように記載されているのか確かめてみましょう。容易に比較できるようこちらもCWE-20解説ページのスクリーンショットをそのまま使います。
長くて大きいですが赤い四角で囲った部分がJVNの「名称補足」で訳されている部分です。CWE-20とはどのような問題どのような対策が取れるのか解説した後に、CWE-20では意図していない用語の定義例として紹介しています。
小さく見えていますが、スクリーンショットの下の方赤枠が問題の「名称補足」の箇所です。明らかにそれ以前のCWE-20解説に当てはまらない誤用・乱用の例として「名称補足」が行われています。
Terminology
The “input validation” term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.
Some people use “input validation” as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean “checking if an input conforms to expectations without changing it.” CWE uses this more narrow interpretation.
以前は赤字の注意事項の記載は無かったと思います。JVNの日本語訳版にも無いです。太字の部分を日本語訳すると
他の人々はより狭いコンテクストで”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用する。CWEはこの狭い意味の解釈を採用している。
JVNの日本語訳では入力バリデーションが全く異なる意味で解釈される可能性があります。可能性があるというより普通はそう誤解してしまうでしょう。
赤字の部分は古いCWE-20には記載されていませんでした。全体を読めばCWE-20で要求している入力バリデーションにはフィルタリングやエスケープなどは含まれていないことは明白です。それでも解らない場合、MITREが公開しているCWE/SANS TOP 25:2011のMonster Mitigation #1やCERT Secure Coding Practices #1を理解していれば誤解の余地はありません。
元のCWE-20のTerminology (Glossary?) はその前に解説されているCWE-20での意味やセキュアコーディングでの意味とは異なる用法（≒ 誤用・乱用）もされている事を紹介しています。なぜCWE-20の言うところの「データの妥当性チェック」と全く異なる「誤用・乱用の意味である」となるような書き方に改悪したのか意味が分かりません。
※ CWEは作られた当初から見ていますが私の知る限りCWE-20の「Terminology」部分が冒頭に記載され、誤用・乱用が「CWE-20でいう所の入力の妥当性チェック」の意味として解説された事はありません。
まとめ
70年代のシステムエンジニアリングの成果に「契約による設計・契約プログラミング」があります。「契約による設計・契約プログラミング」では入力データバリデーション（と状態、出力のバリデーション）を徹底的に行うことにより安全なソフトウェアを作れる仕組みになっています。
あまりに基本的かつ当たり前過ぎて誰も原則として定義していませんが、プログラムで正しく処理されない不正なデータはできる限り早い段階で排除するのが基本原則です。CWE-20はプログラムが意図するデータのみがプログラムに与えられる事を保証していないプログラムは脆弱であるとしている脆弱性分類で、セキュアコーディングの第一原則 ※です。
※ IPAは2017年頃に内容に大きな誤りがあった「セキュアプログラミング講座」を改定し、「CERT Secure Coding Practices」を「セキュアコーディング原則」として公開しいます。
セキュアなソフトウェア作りの第一原則である入力データバリデーション・CWE-20対策が不十分なソフトウェアが安全になるはずがありません。現状のJVNのCWE-20の訳は有害であるとさえ言えます。
実際、とある「セキュリティ専門家」がエスケープやフィルタリングが入力バリデーションに含まれるとする驚くべき出鱈目なCWE-20解説をしています。専門家でさえ間違えてしまうような出鱈目な解説は有害とするしかないのでは？
JVNに送付したメール
酷い誤解の原因となっており、セキュアコーディングの正しい理解を妨げる現在のCWE-20を改悪した訳についてJVNにメールしておきました。その内容を書いておきます。
（追記予定）
件名： JVNのCWE-20の解説の誤訳について
JVN CWE担当者様
jvn.jp で公開されているCWE-20の日本語訳が余計な改悪により「入力の妥当性チェック」にフィルタリングやエスケープが含まれる、とする誤った解釈をしてしまう内容になっています。
JVNのCWE-20の日本語訳では、何故か最後の方に「入力の妥当性チェック」の「誤用・乱用」を紹介した文が最初に部分に記載され、その結果として「誤用・乱用」が意図する意味であるかのように読める内容になっています。
このような間違いが多かったのか、現在のCWE-20では明確に jvn.jp が解説したような意味ではないことを明記しています。
Terminology
The “input validation” term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.
Some people use “input validation” as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean “checking if an input conforms to expectations without changing it.” CWE uses this more narrow interpretation.
https://cwe.mitre.org/data/definitions/20.html場所が適切であれば追加された一文がなくても前の用法は「誤用・乱用」の類であると分かりますが、明確にする文（太字部分）が追加されています。
本来のTerminology（訳した当時はGlossary?）が記載されていた場所（最後の方）であれば、誤解の可能性が若干はあっても、CWE-20の内容本文で解説して意味とは異なる意味で利用されているケースがあること解説だと分かったはずです。
訳自体には問題が無いと言えますが、場所が改悪されているため全く異なる意味での解釈が可能であることは理解頂けたと思います。
セキュリティ専門家と言われる人の中にも、入力バリデーションにフィルタリングやエスケープが含まれる、と誤った解説をしているケースも見られます。
CWE-20（=入力データバリデーション）は現在のIPAのセキュアプログラミング講座でもセキュアコーディングの「第一原則」としている最も重要な原則の一番目です。
IPAのセキュアプログラミング講座の間違いは、指摘したから修正されるまで1年半ほどの時間がかかりました。この間違いの修正は、取り急ぎは改悪された場所の修正と本家CWEで追加された誤解防止用の一文の追加のみでも十分だと考えています。そこまで時間がかからないようお願いします。
よろしくお願い致します。
P.S. セキュアプログラミング講座の間違いを修正された時にはご連絡頂けませんでした。改定に気づくまでかなり時間が必要だったので修正されたらご連絡を頂けると助かります。
注） 旧版 IPAのセキュアプログラミング講座は「入力」と「出力」の区別から間違っているセキュアプログラミングの基礎から誤りがある物でした。
追記
放置してもIPAの出鱈目なセキュリティガイドラインは修正されないようです。「セキュアプログラミング講座」の時のよう直接指摘することにります。
