>>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 とそれに類する情報のみにする。
- クロスサイトスクリプティングはテストされた。同じ検査チームが入力フォームで例として、<script>alert('attack')</script> を入力して確認を行った。
- 「X 日以上使用されていないアカウント」、「ログイン試行回数と失敗回数」、「ユーザのアクセス数を示した表」などのレポートが利用可能でなければならない。
- ファイルの権限についても検査、制限される。
- スーパーユーザ権限で実行されるサービスやジョブは許可されない。
- セッションタイムアウトは設定可能であり、ブラウザはタイムアウト後にはログオフしなければならない(PHP のセッションはすぐに削除されないので、これは Javascript で処理を行わなければならない)。
- 管理者はリモートから強制的にユーザをログアウトさせることができる(これは、手動でデータベースに保存されているセッション情報を削除することができるユーザインターフェースを提供するということである)。
>>セキュリティ関係
*PCRE Heap Overflow
Perl 互換の正規表現ライブラリである PCRE の バージョン 6.1 以下に Heap Overflow の欠陥が見つかっているそうです。PCRE に {...,...} で指定する繰り返しの最大、最小数に 65536 以上の値を指定すると問題になるようです。
PCRE は Python や Apache、PHP など、広く使用されていますが、PCRE に直接正規表現の値を渡すようにしている場合はこの問題の影響を受けるようです。
現在は PCRE 6.3 が公開されています。