## 反例に使う入力の適用範囲

- 成立例、反例、境界値に使う入力や状態は、受入条件が適用される範囲から選ぶ。次のいずれかを記録、コード、文書で示せるものが、この範囲に入る。
  - 要求、仕様、受入条件、または変更前からある利用者向けの契約が、その種類の入力や状態を扱うと定めている。「登録したすべての候補」など、受入条件が対象を集合で示すだけでは足りない。その集合に属する値のうち、どの値が適用範囲に入るかは、以下のいずれかで示す。要求や既存の契約が受け付ける入力の形式そのもの（任意の文字を含む表示名、指定した複数の日付形式など）を定めている場合は、その形式に属する値は記録がなくても範囲に入る。
  - 既存の入力元が、変更前からある操作でその値や形式を作るか、受け渡している。そのことを、利用者向け文書、保存済みのデータや記録、コード、変更前からあるテストで確認できる。入力元が値を検査せずにそのまま受け渡すことだけでは、その形式が使われる根拠にならない。受け渡す値のうち、どの形式が実際に使われるかを、これらの根拠で示す。空白や各国語の文字を含む名前など、入力元で一般に使われる形式は、その形式が使われることを示せばよい。OS や外部ツールで任意の値を作れることだけでは足りない。判定者が新たに考えた操作を説明できることだけでも足りない。
  - 操作する本人以外が作った入力も受け取る。取り込むファイル、他の利用者の入力、連携先の応答などがこれに当たる。この場合は、入力元の契約や文書が定める形式を適用範囲とする。パーサーがたまたま受け付けるだけの形式は含めない。
  - 信頼境界の外から届き、要求、既存の契約、または適用される方針が、その境界での防御を求めている。取得したリポジトリやファイルの内容、ネットワーク入力、連携先の応答、他の利用者の入力が、利用者の環境の特別な設定なしに悪用につながる経路も、この項目と前の項目で扱う。攻撃用の値が普段使われることを示す必要はない。
  - 対象のプログラムが実際の利用でその入力や状態を処理し、失敗した記録がある。実際の利用とは、利用者の操作や運用、またはこの一覧の他の項目で適用範囲に入る入力や状態の処理を指す。検証や計画のために作った値で起こした失敗は含めない。入力と観測結果を特定できることが必要となる。入力を拒否するのが正しい場合、その拒否は失敗に当たらない。
- 型、schema、引数の定義や入口の検証が値を拒否しないことは、適用範囲の根拠にならない。意図して作れば作れることも根拠にしない。前回のレビュー、裁定、検証、計画がその入力や状態を挙げたことや、受入条件として採用したことは、根拠にしない。それに応じて追加したテストや判定、検証や計画のために作った値の記録も根拠にしない。実際の利用での入力と結果を示す記録は、後から集めたものでも上の項目の根拠になる。その反例を根拠に差し戻す側が、適用範囲に入る根拠を示す。前回の検証や計画が挙げた反例も、根拠を確かめてから引き継ぐ。
- 利用者自身の環境変数、シェルの設定、ローカルの設定ファイルなどが特定の状態であることも、それだけでは根拠にしない。利用者の環境を攻撃者が既に改ざんできるという前提も、プロジェクトの方針がその改ざんを防御対象外としていれば根拠にしない。外から入る内容が関わっていても、利用者の環境変数やシェルの設定などが特定の状態であることを前提にしてはじめて悪用が成り立つ場合がある。そのような経路にも、上記の利用者の環境の扱いを適用する。防御対象外と明記された脅威の扱いは、既存の脅威モデルの判定規則に従う。
- 入力が信頼境界の外から来るかは、保存場所や、それを書いた処理では決めない。
  - 誰が入力の値を決められ、誰がどの権限でその値を読む処理を動かすかを確認して判断する。
  - 外から届いた内容や他の利用者の入力は、製品が保存・複製・取得した後も、外から来た入力として扱う。
  - 利用者が自分の環境で状態・設定・記録を管理し、同じ利用者が同じ権限で動かす処理だけが読む場合は、境界の内側として扱う。
  - その状態を誰かが共有・配布するという仮定だけでは、境界の外から来る入力として扱わない。
  - 無視設定などで共有しないのが既定の場合、その設定を外すという仮定だけでも、境界の外から来る入力として扱わない。
  - リポジトリで共有する設定や取り込むファイルなど、製品が共有元から読むことを前提にした入力は、境界の外から来る入力として扱う。
    - その入力が実際に共有・配布されることを、入力を書き込む処理、共有の既定の設定（無視設定、同期・配布の有無）、利用者向け文書、または入力を取り込む処理で示す。
    - 示せない場合は、境界の内側として扱う。
- 値を書き換えられる側が、書き換えずに同じ権限で同じ結果を直接起こせる場合は、その書き換えを前提にした反例を根拠にしない。
- 並行処理や競合を前提にした反例は、同じ資源への操作が実際の使われ方で重なる場合だけ、適用範囲に入る。
  - 操作が重なることは、次のいずれかで示す。
    - 製品自身が処理を並行に動かす。
    - 要求や文書が同時の利用を定めている。
    - 実際の利用で操作が重なり、失敗した記録がある。
  - 人がそれぞれ操作を始める時刻が偶然近くなると仮定するだけでは、操作が重なる根拠にならない。
- 件数・大きさ・長さは、要求・既存の契約・入力元が定める上限か、入力元が実際の使われ方で作る量から選ぶ。
  - バッファや引数の長さなどの技術的な上限を超える量を作れるだけでは、適用範囲に入る根拠にならない。
  - 信頼境界の外から値を指定できる入力では、受け付ける契約の範囲で送れる量も適用範囲に入る。
- 適用範囲に入る根拠を示せない反例は、次のように扱う。
  - 受入条件を満たした修正を、その反例を理由に未完了としない。
  - その反例を理由に、計画に不備があると判定しない。
  - その反例を受入条件、回帰条件、計画の確認項目に加えない。
  - その前提への対策（ロックや排他、書き換えに備えた検証、新しい上限など）を、修正案、受入条件、計画の確認項目として求めない。
  - 懸念として残す場合は、判定を変えない確認事項として1行で記録する。
- 適用範囲に入る入力は、頻度が低くても除外しない。
  - 次の入力や状態も、成立例や反例に含める。
    - 要求・契約・入力元が定める上限に近い件数や長さ
    - 入力元が実際に作る大きなデータ
    - 実際に作られる空の集合
    - 入力元が作る形式のばらつき
    - 製品自身が並行に動かす処理どうしで操作が重なる状態