Differences

This shows you the differences between two versions of the page.

--- ja:rule:入力 [2017/06/30 11:46] – [入力] yohgaki
+++ ja:rule:入力 [2017/10/26 11:28] (current) – [ルール] yohgaki
@@ Line 3: / Line 3: @@
 入力処理の基本原則は
-  * ゼロトラスト - 全てを信頼しない（検証済みのモノ以外、データおよびコード、は信頼できない）
+  * **ゼロトラスト** - 全てを信頼しない（検証済みのモノ以外、データおよびコード、は信頼できない）
-  * ホワイトリスト - 許可するモノを設定する（入力仕様に従い許可する入力のみ受け入れる）
+  * **ホワイトリスト** - 許可するモノを設定する（入力仕様に従い許可する入力のみ受け入れる）
-である。信頼境界で全ての入力に対してこの２原則を適用する。全ての信頼できない入力値に対して
+である。信頼境界で全ての入力に対してこの２原則を適用する。全ての信頼できない入力値に対して次のバリデーションを行う。
-  * 文字エンコーディング - Webアプリへの入力は基本的にテキスト形式（$_GET,$_POST,$_COOKIE,$_ENV,HTTP,HTML,JavaScript,JSON,DB,LDAP,XML,SMTP,etc)
-  * 長さ - 最小および最大（文字列・バイトデータの場合）
-  * 範囲（数値型の場合）
-  * 形式 -
+  * **入力値の個数** - 必須／オプション入力以外の入力を含む場合は拒否
+  * **入力ソース** - クエリパラーメーター($_GET)のみを必要とする場合、$_POST、$_FILESなどに要素がある場合は拒否
+  * **データ型** - PHPの場合、$_GETなどの要素に文字列型と配列型のデータが初期化される。(?var[]=abc&var[]=def)
+  * **文字エンコーディング** - Webアプリへの入力は基本的にテキスト形式（$_GET,$_POST,$_COOKIE,$_ENV,HTTP,HTML,JavaScript,JSON,DB,LDAP,XML,SMTP,etc)
+  * **長さ** - 最小および最大（文字列・バイトデータの場合）
+  * **形式** - 電話番号、メールアドレスなどの形式が決まった文字列
+  * **文字** - 利用する文字種(英数字のみ、平仮名のみなど）
+  * **範囲** - 最小および最大（数値型の場合）
+外部入力とは「自分か完全に管理するコード」に「静的に記述されていない値全て」である。全ての外部入力は検証する。入力が信頼可能であることを検証＆保証可能である場合は信頼する（信頼境界内に入れる）ことも可能である。しかし、仕組み上信頼不可能である場合も多く、不用意な信頼はリスク増加要因である。
 ソフトウェアの信頼境界には限界がある。同一プロセス・スレッド上で動作する「自分か完全に管理するコード」以外のプログラムからの入力は、基本的に信頼することができない。
-例： Webブラウザからの入力 - 自分が管理するJavaScriptプログラムで制御された入力がWebブラウザ上から送信される場合でも、これらの入力は信頼できない。
+> 例： Webブラウザからの入力 - 自分が管理するJavaScriptプログラムで制御された入力がWebブラウザ上から送信される場合でも、これらの入力は信頼できない。
 Webサーバーに対するWebブラウザからの入力は、自分が管理するWebページを経由しなくても送信可能である。従って、Webサーバーに対する入力が確実に受け入れ可能であることを保証できない。Webブラウザからの全ての入力は信頼できないので、全て検証（バリデーション）しなければならない。
-例外： 信頼できる計測機器/データベースなどデバイス/アプリ（OS、アプリが信頼できる）が信頼できるネットワークを利用して送信してきた安全な入力データ
+> 例外： 信頼できる計測機器/データベースなどデバイス/アプリ（ハードウェア、OS、アプリが信頼できる）が信頼できるネットワーク（エンドツーエンドで暗号化されている、等）を利用して送信してきた安全な入力データ
 送信元、通信経路およびデータの安全性が検証・保証されている場合、その入力は信頼することができる。例えば、信頼できるRDBMSから送信されてきた整数型のレコードIDは信頼できる。ただし、信頼できるシステムからの入力の場合であっても、データの安全性が保証できない場合は信頼できない。外部システムの入力を信頼する場合、リスクが増加することに留意する。例えば、SQLite３データベースのカラムはカラムのデータ型定義に関わらず文字列型データを保存できる。このような外部システムの場合、数値型カラムのデータであっても、データの保存と管理が十分な安全性を保証できない限り、信頼することはできない。
@@ Line 27: / Line 31: @@
 入力データには３種類が存在する。
-  * 正しいデータ
+  * **正しいデータ**
-  * 入力ミスのデータ
+  * **入力ミスのデータ**
-  * 不正なデータ
+  * **不正なデータ**
+入力仕様に則り「不正なデータ」は確実に入力処理（MVCモデルのコントローラー）で拒否されなければならない。「入力ミスのデータ」はビジネスロジック（MVCのモデル）により適切に処理される。
-入力仕様に則り「不正なデータ」は確実に入力処理で排除されなければならない。「入力ミスのデータ」はビジネスロジック（MVCのモデル）により適切に処理される。
 ===== ルール =====
+  * [[.:inp:入力文字エンコーディングをバリデーションする]]
   * [[.:inp:バリデーションする前に全ての変換作業を行う]]
+  * [[.:inp:文字列を正規化する]]
   * [[.:inp:デフォルトで初期化される外部入力をバリデーションする]]
   * [[.:inp:正規表現に用いられる入力データにメタ文字がないことを確認する]]
   * [[.:inp:入力バリデーションにブラックリスト方式を用いない]]
-  * [[.:inp:入力文字エンコーディングをバリデーションする]]
+  * [[.:inp:不要な入力パラメーターを含む場合に拒否する]]
+  * [[.:inp:入力を拒否した場合に適切な対応措置を取る]]
+  * [[.:inp:入力が信頼できる物であることを検証する]]
+  * [[.:inp:署名、暗号化したデータのみを信頼する]]
+  * [[.:inp:複数のCSRFトークンを利用する]]
+===== 参考文献 =====
+  * https://blog.ohgaki.net/owasp-secure-coding-practices-quick-reference-guide
+  * https://blog.ohgaki.net/cert-top-10-secure-coding-standard
 ===== 注意事項 =====
@@ Line 45: / Line 62: @@
 出力対策は入力対策とは”**独立**”した対策である。出力対策は入力対策の有無に関わらず、出力対策のみで安全性を保証しなければならない。
+入力コードでは「入力のコンテクスト」（データの種別）に応じたバリデーションを行う。出力コードでは「入力のコンテクスト」を判別できない場合がある。また、出力コードでは「出力先のコンテクスト」（出力先の種別、例：SQLならパラメーター、識別子、SQL語句）に応じたセキュリティ処理が必要となる。このため、入力コードでのデータバリデーションと出力コードでのデータバリデーションは異るモノである。
+入力バリデーションエラーとなる入力は「不正なデータ」であり、正しく処理することが不可能なデータである。**Fail Fast原則**（出来る限り早く失敗させる原則）に則り、「不正なデータ」の拒否はソフトウェアがデータを受け入れた直後に行う。