development guideline/ASP.NET/Security

'development guideline/ASP.NET/Security/' には、下位層のページがありません。

基本方針 †

入出力を厳密に検証する †

• ユーザーに対して自由な値を入力を許可する場合、値受け取り時にその値の妥当性を検証するコードを必ず実装する。
• 妥当な入力値以外は、入力値検証時に全て除外する。
• 以降の処理は、妥当な値が入力されていること前提に実装してもよい。

問題発生時には、処理継続させない。機能停止させる †

• 例えば「システムエラーを避けるためだけに例外出力コードを実装しない」ということの無い様に留意する。

最小特権 †

• 必要最小限の操作だけを行えるように、システム権限を設定する。（主に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コマンド・インジェクション †

• シェルを起動する実装を避ける。

SQLコマンド・インジェクション †

• SQL文の生成にバインド機構を使用する。
  • 上記が実現できない場合は、全ての変数にエスケープ処理が必要。
• SQLエラーメッセージをブラウザにそのまま表示しない

バッファオーバーフロー †

• ループの終了条件でバッファ境界をチェックする。
• 書き込み先バッファサイズを指定する。
• 上限サイズのバッファを用意する。
• 与えるデータサイズを制限する。
• バッファオーバーフロー対策ツールを利用する。

クライアントサイドアタック †

クロスサイト・スクリプティング †

• Webページに出力する全ての要素に対して、エスケープ処理（サニタイジング）を施す。
• エスケープ処理は、ASP.NETのコントロール群に任せ、基本的には個別に実装しない。（独自ルール）（動的javascript埋め込み等、リテラル処理を行う箇所は例外）
• スタイルシートを外部サイトから取り込めるようにしない

ロジカルアタック †

クロスサイト・リクエスト・フォージェリ(CSRF) †

• 全ページのPOSTパラメータに秘密情報を挿入し、サーバで記録していた値と比較する。

プロセスフロー管理の不備 †

• 不正な画面遷移を防ぐために、TransactionTokenを利用する。特に登録系ページ等では必須。
• 重要なデータ処理の直前はPOST動作にする。GETを使わない。

その他 †

HTTPヘッダ・インジェクション †

• 外部から渡されるパラメータを、直接HTTPヘッダ情報として用いない。
  • 上記が実現できない場合は、レスポンスヘッダ記述用APIを用いたり、改行を削除する。

バックドアとデバッグオプション †

• 実装用、または試験用にバックドアやデバッグオプションが必要な場合は、ユーザに指定できない方式とする。