基本方針 †
入出力を厳密に検証する †
- ユーザーに対して自由な値を入力を許可する場合、値受け取り時にその値の妥当性を検証するコードを必ず実装する。
- 妥当な入力値以外は、入力値検証時に全て除外する。
- 以降の処理は、妥当な値が入力されていること前提に実装してもよい。
問題発生時には、処理継続させない。機能停止させる †
- 例えば「システムエラーを避けるためだけに例外出力コードを実装しない」ということの無い様に留意する。
最小特権 †
- 必要最小限の操作だけを行えるように、システム権限を設定する。（主にDB、OS等インフラ）
権限分割 †
- 利用者の権限を細かく分割する。（主にDB、OS等インフラ）
認証 †
HTTPSの不備 †
- 個人情報取り扱いページは、HTTPS通信とし、HTTP通信を許可しない。
- 画像ファイル等であっても、個人情報となり得るものは全て対象。
- Cookieに認証情報を格納する場合には、必ずsecure 属性を付ける。
認証設定の不備 †
- 規則性があり推測しやすい利用者ID、パスワードを自動生成しない。
- 利用者ID、パスワードを入力する画面（ログイン画面）で、HTTPS通信を実施する。
- ログインが必要な全てのコンテンツについて、描画処理前にログインを確認する処理を挿入する。
- 認証エラーで登録情報を暴露しない。ID不在、パスワード誤り時のメッセージを同一にする。
- クレジットカード番号等の秘密度が高いものは、SSL 経由であれ全ての情報は表示しない（下4桁など）こと。
ブルートフォース攻撃 †
- ログイン、ファイル名指定機能、セッションID等について、一定の閾値を設けて、閾値を越えた場合には要求を受け付けないようにする。
- セッションIDや、Kerberosチケット等の一時認証キーは、有効期間をできるだけ短時間に設定する。
パスワードリマインダ †
- できるだけ、質問内容はユーザーの自由登録とし、選択式にはしない。
- 利用時には、3つ以上の登録情報を要求する。うち、ログインIDを必ず含める。
承認 †
セッション管理 †
- セッションIDを推測が困難なものにする。
- できるだけ、セッションIDをURLパラメータに格納しないようにする。
- ログイン成功後に、新しくセッションを開始するようにする。
- 上記が実現できない場合は、セッションIDとは別に秘密情報を発行し、ページ遷移毎にその値を確認する。
- セッションIDをCookieにセットする場合、有効期限の設定に注意する。
- 状態はできるだけサーバー側に持たせる。（=Cookieを使わない）
- ブラウザ側にはセッションIDのみを渡す。Cookie等にデータを載せない。つまり、Response.Cookiesオブジェクトは利用しない。
- Webサイト閲覧時に自動ログインする場合など、どうしてもCookieにデータを保存させたい場合には、複数の識者に相談し、保存するデータの内容や動作仕様について十分検討する。
セッション終了処理 †
- ログアウト(ボタン)を設置する。
- タイムアウト時間を設定する。（通常1時間以内）
情報取得 †
システムのバージョンに関する情報 †
- システムのバージョン情報は秘匿する。（ASPのエラー画面、HTTP Header等）
サーチエンジンによって公開される情報 †
- サーバー上に不要なコンテンツを置かない。（例え、ハイパーリンクされていなくても）
強制ブラウジング †
ディレクトリ・トラバーサル †
- パラメータで、サーバー内のファイルを指定できる実装を避ける。
- 上記が実現できない場合は、Webアプリが参照できるフォルダの範囲を適切に設定する。
HTMLソースコメント †
- HTMLソースに不要なコメントを記述しない。
- 開発用のコメントはHTMLコメントで記述しない。Aspxファイルであっても、C#コメントとして記述する。
コマンド実行 †
OSコマンド・インジェクション (36) †
・ シェルを起動する実装を避ける。
2.4.2 SQLコマンド・インジェクション (39)
・ SQL文の生成にバインド機構を使用する。
上記が実現できない場合は、全ての変数にエスケープ処理が必要。
・ SQLエラーメッセージをブラウザにそのまま表示しない
2.4.3 バッファオーバーフロー (44)
・ ループの終了条件でバッファ境界をチェックする。
・ 書き込み先バッファサイズを指定する。
・ 上限サイズのバッファを用意する。
・ 与えるデータサイズを制限する。
・ バッファオーバーフロー対策ツールを利用する。
2.5 クライアントサイドアタック
2.5.1 クロスサイト・スクリプティング (58)
[HTMLテキストの入力を許可しない場合]
・ Webページに出力する全ての要素に対して、エスケープ処理を施す。
エスケープ処理は、ASP.NETのコントロール群に任せ、基本的には個別に実装しない。（独自ルール）（動的javascript埋め込み等、リテラル処理を行う箇所は例外）
・ スタイルシートを外部サイトから取り込めるようにしない
2.6 ロジカルアタック
2.6.1 クロスサイト・リクエスト・フォージェリ(CSRF) (65)
・ 全ページのPOSTパラメータに秘密情報を挿入し、サーバで記録していた値と比較する。
2.6.2 プロセスフロー管理の不備 (69)
・ 不正な画面遷移を防ぐために、予約ページ等ではTransactionTokenを利用する。
・ 重要なデータ処理の直前はPOST動作にする。GETを使わない。（独自ルール）
2.7 その他
2.7.1 HTTPヘッダ・インジェクション (80)
・ 外部から渡されるパラメータを、直接HTTPヘッダ情報として用いない。
上記が実現できない場合は、レスポンスヘッダ記述用APIを用いたり、改行を削除する。
2.7.2 バックドアとデバッグオプション (84)
・ 実装用、または試験用にバックドアやデバッグオプションが必要な場合は、ユーザに指定できない方式とする。（独自ルール）
![[Return to Top Page]](image//logo.png "[Return to Top Page]"){kind=logo}
