Web Application Security Reviews

セキュリティ

PHP Everywhere に Web Application Security Reviews という、投稿がありました。
非常に興味深かったので、訳してみました。金融機関で受けた Web アプリケーションのセキュリティチェック項目をまとめたものだそうですが、結構厳しいです。

誤訳などがありましたら指摘していただけますと幸いです。

  • 全ての重要な作業過程において、開発側と検査側を含めなければならない。言い換えると、もし私(開発側)が重要な案件を作成する場合、他の誰か(検査側)の検査と承認を受けなければならない。
  • 取引の活発な団体の全ての取引において、ユニーク ID と(前後の)変更データ、タイムスタンプを保存しなければならない。
  • PHP または ASP で使用される全てのデータベースのパスワードは暗号化されていなければならない。
  • もし、Web アプリケーションがインターネットに公開される場合は Tripwire(ファイルの更新を検出するツール)がインストールされていなければならない。
  • データベース接続(とパスワードの復号)は DLL かコンパイル済みのスクリプトを通して行わなければならない。
  • パスワードの鍵はコンパイル済みのコードにおいても平文で格納せず、分かりにくくする、または、分割して複数に分割して格納するべきである。
  • ユーザは初回ログイン時にパスワードを変更しなければならない。
  • 全てのデータベースパスワードは銀行が好むアルゴリズム(例: SHA-1, 3DES, AES など)を使用して暗号化されなければならない。
  • 全てのユーザのパスワードは銀行が好むアルゴリズム(例: SHA-1, 3DES, AES など)を使用して暗号化されなければならない。
  • ユーザは X 回ログインに失敗するとロックアウトされる。主要な管理者は例外とする。
  • ユーザはログインを禁止される可能性がある。
  • 高い権限を持つアカウントの全ての重要なパスワードは2人で分割して持っていなければならない。
  • 全てのパスワードはアルファベットと数字が混ざっていなければならない。また、パスワードの最小の長さを設定できなければならない。
  • パスワードは X 日ごとに変更されなければならない。通常は30日から90日である。
  • パスワードは X 回以上繰り返し使用することはできない。今までに見た最高の値は24回である。
  • パスワードとユーザ ID の最初の X 文字が同じであってはならない。
  • セッションキーは[session_regenarate_id() を使用して]ログインごとに再生成されなければならない。セッションキーが再生成されていることと、次の項目を確認するために、検査チームがパケットキャプチャを行う HTTP プロキシサーバを使用したこともあった。
  • Cookie に重要な情報を格納してはならない。例: セッション ID とそれに類する情報のみにする。
  • クロスサイトスクリプティングはテストされた。同じ検査チームが入力フォームで例として、 を入力して確認した。
  • 「X 日以上使用されていないアカウント」、「ログイン試行回数と失敗回数」、「ユーザのアクセス数を示した表」などのレポートが利用可能でなければならない。
  • ファイルの権限についても検査、制限される。
  • スーパーユーザ権限で実行されるサービスやジョブは許可されない。
  • セッションタイムアウトは設定可能であり、ブラウザはタイムアウト後にはログオフしなければならない(PHP のセッションはすぐに削除されないので、これは Javascript で処理を行わなければならない)。
  • 管理者はリモートから強制的にユーザをログアウトさせることができる(これは、手動でデータベースに保存されているセッション情報を削除することができるユーザインターフェースを提供するということである)。