アプリケーションセキュリティ検証標準 (ASVS) のバージョン 5.0 を準備する中で、5.0 の要件に含めたくない既存および新規に提案された項目が多数あることが明らかになりました。これは 5.0 の定義により ASVS の範囲ではないか、あるいは、良いアイデアであったとしても、必須とすることはできないと考えたためです。
私たちはこれらの項目を完全に失いたくなかったので、この付録でその一部を取り上げることにしました。
以下の項目は ASVS の範囲内です。私たちはこれらを必須にすべきとは考えていませんが、セキュアアプリケーションの一部として考慮することを強くお勧めします。
- パスワード強度メーターを提供して、ユーザーがより強力なパスワードを設定できるようにする。
- アプリケーションのルートまたは .well-known ディレクトリに一般に利用可能な security.txt を作成して、セキュリティ問題について所有者に連絡するためのリンクまたは電子メールアドレスを明確に定義する。
- 信頼できるサービス層でのバリデーションに加えて、クライアントサイドの入力バリデーションを実施すべきである。これは何者かがアプリケーションを攻撃しようとしてクライアントサイドのコントロールをバイパスしたことを発見する良い機会を提供するためである。
- robots.txt ファイル、X-Robots-Tag レスポンスヘッダ、または robots HTML meta タグを使用して、間違ってアクセス可能な機密ページが検索エンジンに表示されることを防ぐ。
以下の項目は以前 ASVS にありましたが、実際には要件ではありません。むしろ、セキュリティコントロールを実装する際に考慮すべき原則であり、これに従うと、より堅牢なコントロールにつながります。以下があります。
- セキュリティコントロールは集中管理され、簡潔 (経済的設計) で、検証可能で、セキュアで、再利用可能であるべきです。これによりコントロールの重複、欠落、効果がないものを回避できます。
- 理想的には、保護されたデータおよびリソースにアクセスするために、単一の十分に検証されたアクセス制御メカニズムを使用すべきです。コピー＆ペーストやセキュアではない代替パスを回避するために、すべてのリクエストはこの単一のメカニズムを通過すべきです。
- 属性または機能ベースのアクセス制御は推奨パターンであり、コードが単に役割ではなく機能やデータ項目に対するユーザの認可を確認しています。権限は引き続き役割を使用して割り当てるべきです。
ASVS 5.0 から削除されたセキュリティプロセスが多数ありますが、それはまだ良いアイデアです。これらのプロセスを効果的に実装する方法については、OWASP SAMM プロジェクトが優れた情報源となるかもしれません。以前 ASVS に含まれていた項目には以下のものがあります。
- 開発のすべての段階でセキュリティに対処するセキュアソフトウェア開発ライフサイクルを使用する。
- 脅威を特定し、対応策を計画し、適切なリスク対応を促進し、セキュリティテストをガイドするために、設計変更やスプリント計画ごとに脅威モデリングを使用する。
- すべてのユーザストーリーと機能に「ユーザとして、自分のプロフィールを閲覧および編集できる必要がある。他の人のプロフィールを閲覧または編集できないようにする必要がある」のような機能的なセキュリティ制約が含まれている。
- セキュアコーディングチェックリスト、セキュリティ要件、ガイドライン、ポリシーがすべての開発者とテスト担当者に利用可能である。
- アプリケーションのソースコードには、バックドア、悪意のあるコード (サラミ攻撃、ロジックボム、時限爆弾など)、文書化されていない機能や隠された機能 (イースターエッグ、安全でないデバッグツールなど) がないことを確認するための継続的なプロセスが存在する。このセクションに準拠するには、サードパーティライブラリを含むソースコードへの完全なアクセスなしには不可能であり、したがって、最高レベルのセキュリティを必要とするアプリケーションにのみ適していると考えられる。