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 で処理を行わなければならない)。
• 管理者はリモートから強制的にユーザをログアウトさせることができる(これは、手動でデータベースに保存されているセッション情報を削除することができるユーザインターフェースを提供するということである)。