2025年2月21日

NECサイバーセキュリティ戦略統括部　セキュリティ技術センターの伊藤です。
業務では、NECが推進するセキュリティ提案・実装のための社内向けシステムの開発を担当しています。
今回のブログでは、Webアプリケーションにおけるセキュリティを検証するための明確な標準を提供するOWASPアプリケーションセキュリティ検証標準（ASVS: Application Security Verification Standard）[1]について紹介します。

目次

ASVSとは

OWASPアプリケーションセキュリティ検証標準（ASVS）は、OWASP[2]により提供されている、安全なWebアプリケーションの実現のために必要なセキュリティ事項に関する包括的な文書であり、アプリケーションに関わる様々なステークホルダーがセキュリティを定義、構築、及び検証する際の共通的な指針として多くの企業で利用されています。
ASVSをベースとすることで、組織はアプリケーションに対して、過多でもなく、過少でもない適切なセキュリティ対策を実施することができます。また、ベンダー等との契約においては、ASVSで定義されたセキュリティの基準を指定することで、プロジェクトで明確かつ一貫したセキュリティのベースラインを維持することができます。

ASVSの信頼性

ASVSは信頼性の高いセキュリティスタンダードとして、多くの企業で活用が進められています。
ASVSはこれまでのOWASPにおける取り組みや多くのセキュリティ専門家の豊富な経験を基に作成されており、2009年の初版リリース以来、定期的な改訂が行われ、最新の脅威や攻撃動向を反映した内容となっています。
また、ASVSはNIST[3]のフレームワークと整合性を持つように設計されていることが示されており、NISTのフレームワークに準拠しつつ、より具体的なセキュリティ実装やテスト項目について検討することができます。さらにASVSのほとんどの項目には、共通脆弱性タイプ一覧（CWE）[4]との対応が示されているため、他のツールや以前のASVSのバージョンとの互換性についても考慮されています。
今日では、グローバルでの活用も進められており、安全なWebアプリケーションの実現のための評価項目や開発ガイドラインとして活用されています。

ASVSの活用事例

日本では、2020年に一般社団法人コンピュータソフトウェア協会（CSAJ）[5]とSoftware ISAC[6]が共同でASVS 4.0の日本語訳[7]を公開しており、国内の企業や開発者に向けたASVSの利便性の向上を図っています。また、CSAJはASVSに関する勉強会や検証プログラムの提供も行っており、ASVSの普及活動を積極的に進めています。
海外では、国際的なサイバーセキュリティ業界の非営利団体であるCREST[8]がASVSを基準とした認証プログラム[9]を提供しており、今日、世界中の多くの企業や政府でASVSをWebアプリケーションのためのセキュリティスタンダードとして採用する動きがあることが示されています。

ASVSの改訂履歴

ASVSは日々加速する様々な脅威や攻撃手法を考慮し、定期的な改訂が行われています。

現在の最新はバージョン4.0.3であり、次のバージョン5.0に向けた計画とロードマップ[10]が発表されています。

ASVSの使い方

次にASVSの使い方について説明します。
ASVSを効果的に活用するため、まずは、適切なセキュリティの検証レベルの設定を行い、その後、実際のユースケースに合わせて、実施内容の調整を行います。

検証レベルの設定

検証レベルの定義を表1に示します。

各組織では、想定されるリスクやビジネス要件に基づいて、適切な検証レベルを設定することが強く推奨されています。これにより、各セキュリティ対策が過不足なく実施されることが保証され、適切なセキュリティとコストのバランスが達成されます。

実施内容の調整

実際には、アプリケーションの特性に基づいて、セキュリティ項目ごとに異なる検証レベルを設定することも考えられます。例えば、ある項目については、レベル1の基本的な対策で十分であるが、他の項目については、レベル2やレベル3の高度な対策が必要となる場合があります。
ASVSの内容は実際のユースケースに合わせて、調整・詳細化されることで、組織のプロジェクトや環境にとって、最も重要なセキュリティ要件に焦点を当てることが推奨されています。
また、決定されたセキュリティの実施内容については、例えば、開発時に参照しやすいように、アプリケーション固有のセキュアコーディングチェックリストとして作成することもできます。

ASVSの各セキュリティカテゴリの概要

この章では、ASVSが定義する各セキュリティカテゴリの概要について紹介します。バージョン4.0.3では、14のカテゴリが定義され、アプリケーションに必要なセキュリティ対策を体系的かつ効果的に実施できるように整備されています。
セキュリティカテゴリの概要について表2に示します。

アプリケーションの安全性を確保するためには、各セキュリティカテゴリの理解と適切な対策が必要です。以降、ASVSを開発のガイドラインとして参照する場合を想定し、一開発者である執筆者個人としてWebアプリケーション開発時にポイントとなるセキュリティの考え方を交えつつ、いくつかのカテゴリにおけるガイドラインの内容を簡単に紹介します。

V1 アーキテクチャ、設計、脅威モデリング

アプリケーション開発の成功の鍵は、シフトレフト[12]の考え方にあります。
このカテゴリでは、アプリケーションの設計段階からセキュリティを組み込むためのガイドラインが提供されています。
以下に示す1.1.1の項目では、開発のすべての段階でセキュリティを考慮したセキュアなソフトウェア開発ライフサイクルを使用することが推奨されています。

セキュリティへの考慮が後回しにされたアプリケーションでは、後に欠陥が発見された際の修正の複雑性や影響範囲が開発初期段階から増大しており、修正が容易ではない可能性があります。また、セキュリティチェックが遅れることで、一部の脆弱性が見過ごされ、リリース後に重大なセキュリティ問題が発生するリスクが高まります。そのため、脅威モデリングを通じて潜在的な攻撃ベクトルを特定し、開発の初期段階からセキュリティを考慮することが重要です。これにより、問題が発見された場合の修正コストを大幅に削減することができます。

V2 認証

皆さんのパスワードは安全と言えるでしょうか。
認証カテゴリでは、パスワードの強度や保存方法、多要素認証の導入など、認証に関するベストプラクティスについて、NIST 800-63b[13]のガイドラインと併せて紹介されています。
ユーザのアカウントを攻撃者による不正なアクセスから保護するために、ASVSのガイドラインでは、パスワードの長さや複雑さを確保するためのポリシーを設定することや多要素認証（MFA）を導入することで、万が一、パスワードが漏洩した場合でも追加のセキュリティ層を提供することが推奨されています。
また、認証情報の保管に関しては、ハッシュ化やソルトなどの技術について推奨される具体的な設定値と共に示されています。
さらに、以下に示す2.2.1の項目では、自動化された攻撃に対する効果的な防御策について示されています。

ユーザが設定するパスワードに対する考慮だけでなく、上記のようなシステム側でのセキュアな仕組みを用意しておくことは、今日の高度化・巧妙化する多くの脅威に対して有効であり、アプリケーション開発として当然組み込まれるべき要素であると思います。

V4 アクセス制御

誰が何にアクセスできるのか決める必要があります。
アクセス制御カテゴリでは、ユーザやシステムがどのリソースにアクセス可能であるかについて管理するためのガイドラインが提供されています。
ここでは、役割ベースのアクセス制御（RBAC）などのアクセス制御ルールを導入し、ユーザごとに適切なアクセス権限を設定することが推奨されています。また、アクセス制御ポリシーの定期的な見直しと更新を行い、新たな脅威や環境の変更に対応することも重要です。
さらに、ユーザに対して最小権限の原則を適用し、認可されたサービスや機能、ファイルにのみアクセスできる状態とすることが求められます。必要最低限の権限のみを付与することで、データ漏洩やサービス停止などのセキュリティリスクを最小限に抑えることができます。

V5 バリデーション、サニタイズ、エンコーディング

多くの場合、入力データは攻撃の入り口となります。
このカテゴリでは、ユーザからの入力データを検証し、適切なサニタイズ（無害化）やエンコーディングの処理を行うための方法が紹介されています。
以下に示す5.1.3の項目では、様々な種類の入力データに対して、あらかじめ定義されたホワイトリストによる検証を行うことが推奨されています。

これは、攻撃者による意図的な不正な入力を防ぐことができるだけでなく、ユーザによる偶発的な入力ミスを検出することにも役立ちます。システムに開発者が予期しないデータが入力され、保存されていると、内部データの不整合により、これまで正常に動作していた別の機能で問題が発生し、原因の特定・修正に時間を要する場合もあります。堅牢なアプリケーションの実現のため、入力データの検証は基本的かつ重要な要素であると思います。
また、ガイドラインでは、サニタイズ処理を通じて、入力データから悪意のあるコードを除去し、適切なエンコーディング処理を行うことで、データを安全に処理することが全ての検証レベルで推奨されています。
これらの対策は、クロスサイトスクリプティング（XSS）やSQLインジェクションなどのアプリケーションに対する主要な攻撃に対して有効です。

V7 エラー処理とログ記録

エラー処理とログ記録は、特にインシデント対応において必要不可欠な情報を提供します。
このカテゴリでは、エラー処理とログ記録に関するガイドラインが提供されています。
エラー処理では、ユーザに対して表示するエラーメッセージにシステムの内部情報や秘密情報が含まれないように注意する必要があります。
また、ログの管理においては、システムの動作やセキュリティイベントを適切な粒度で記録し、後にインシデントが発生した場合に必要な分析が行えるようにしておくことが求められます。
例えば、ログにはアクセスの試行や失敗、システムエラーなどの情報を含め、定期的に監視と分析を行うことで、不正な活動を早期に検出することができます。
さらに、ログデータの保護についても、不正なアクセスや改変から防ぐための適切なセキュリティ対策を講じることが重要です。
以下に示す7.4.1の項目では、予期せぬエラーが発生した場合にサポート担当者が調査に使用できるユニークなIDを含む一般的なメッセージが表示されることが望ましいとされています。

開発者の予期しないエラーについては、原因調査が難しい傾向にありますが、ログにスクリプトのどの行でどのような種類のエラーが発生したか記録しておくことで、開発者が継続的にログを分析し、エラーの傾向を知ることができます。これを元に、適切なエラー処理の実装や機能の改善を行うことで、ユーザの利便性の向上を図ることができます。

V10 悪意のあるコード

悪性コードや不要な機能が含まれないことを確認してください。
このカテゴリでは、アプリケーションで使用しているソースコード内に攻撃の起点となる悪性のコードが含まれないか確認することに焦点を当てています。
サードパーティのライブラリを含むコード内に不正な通信またはデータ収集のための機能、またロジックボムやバックドア等が含まれていないことを確認する必要があります。確認にあたっては、悪性コードを自動検出できるコード分析ツールの使用も推奨されています。
また、アプリケーションがデプロイされた後も、悪性コードが挿入される可能性があります。更新されるコードのデジタル署名の検証やドメイン名の有効期限の定期的な確認が推奨されます。

まとめ

本ブログでは、OWASPアプリケーションセキュリティ検証標準（ASVS）について紹介しました。
ASVSを活用することで、組織はWebアプリケーションに対して、適切なセキュリティ対策を実施し、プロジェクトで一貫したセキュリティのベースラインを維持することができます。今後のプロジェクトでのセキュリティ指標や、既存のプロジェクトのセキュリティ検証のために、ご活用いただければと思います。

参考文献

執筆者の他の記事を読む