More than 1 year has passed since last update.

OWASP ASVS（Application Security Verification Standard）の目的と活用例

Last updated at 2022-05-09Posted at 2022-05-06

こんにちは。@okazu_dm です
この記事では、OWASP ASVS（Application Security Verification Standard）について、エーアイセキュリティラボの視点でご紹介したいと思います。

Webアプリケーションのセキュリティに関する基準を定めている企業・団体はいくつかありますが、特に広く知られているのがOWASP¹です。今回ご紹介するOWASP ASVSのほか、Webアプリケーションのセキュリティに関する10大脅威をまとめたOWASP Top 10²があります。

ASVSはOWASP Top 10に比べて広い範囲をサポートしており、一般的なソフトウェア開発のベストプラクティスなども含まれていることから、よりセキュアなアプリケーション開発に適していると考えられます。
どういった点で適しているのか、ASVSの目的、活用例や検証項目の各章の解説を通じてみていきましょう。

ASVSの概要

ASVSはOWASPコミュニティの主導で公開されているセキュリティ要件やテストのリストです。

OWASPの公開文書によると、ASVSはリストそのものを指すという風に書かれていますが、ここではそれを含む文書全体も便宜上ASVSと呼んでいます。

Webアプリケーション及びWebサービスの設計、開発、テストの際に利用可能なセキュリティ要件、管理策のフレームワークとして作成されており、具体的には14個のカテゴリに分類されて開発のライフサイクルや設計、実装についての各種検証要件が記述されています。

対象バージョン

OWASP ASVS 4.0.1

レベルについて

ASVSでは3段階のレベルが定義されており、レベル1が低保証レベル(low assurance level)向けとされ一番低く検証要件数も一番少なくなっています。
それぞれのレベルの概要と検証要件数は以下の通りです。

レベル	概要	検証要件数
レベル1	すべてのアプリケーションが目指すべき必要最低限のレベル	131
レベル2	今日のソフトウェアに関連するリスクのほとんどを適切に防御できれば達成できるレベル	267
レベル3	通常、軍事、安全衛生、重要インフラなどの分野で見られるような、重大なレベルのセキュリティ検証を必要とするアプリケーションを想定しているレベル	286

これは筆者の所見ですが、項目のチェックのしやすさや汎用性から、まずはレベル1でASVS準拠のプロセスを確立し、組織内に浸透させてから次のレベルを目指すという進め方が良いかと思います。

レベル間の違いの参考として、ASVSの公式リポジトリ³から引用した図をもとにレベルごとの対象や検証の方法について示します。

NIST SP 800-63との対応について

ASVSでは、NIST SP 800-63(またはその付随文書)について触れられており、一部の検証要件ではNIST側の記述へのマッピングがされています。

これに関しては、そのままNIST側の記述を採用しているわけではないケースもあります。
例として、パスワードの文字数についての要件はそれぞれ以下のようになっています。

ASVS 4.0.1 V2.1.1: 最低12文字
NIST SP 800-63b 5.1.1.2: 最低8文字

ASVSの活用例

ASVS自体は主要な目的として以下の2つを掲げており、それらの目的に沿っていくつかの活用方法が紹介されています。

セキュアなアプリケーションを開発、メンテナンスを支援すること
セキュリティサービスベンダ、セキュリティツールベンダ、利用者がそれぞれの要求と提供するサービスを調整できるようにすること

具体的な活用方法の一つとしては、アプリケーション、プラットフォーム、セキュアコーディング時のチェックリストのプロトタイプとして使うことを勧めています。また、開発時の単純なチェックリストとしての利用以外にも、下記のような活用方法が挙げられており、実装担当者以外にも幅広く利用できるものとなっています。

セキュリティアーキテクチャの手引として
セキュアな開発のトレーニングとして
セキュアなソフトウェアの調達を推進する際のフレームワークとして

検証方法と活用する際の注意点

ASVSの3つのレベルのうち、レベル1は人間によるペネトレーションテストが可能であり、それ以外はドキュメントやソースコード、開発に関わる人々へのアクセスが必要とされています。
方法に関してはいくつかの箇所に分散して以下のような注意が書かれています。

レベル1がブラックボックステストによって検証可能であったとしても行うべきではなく、開発者やドキュメント、ソースコードへのアクセスを確保してテストを行うことを推奨する
レベル1の要件に限定すると大部分は自動テストを使用して実行可能だが、レベル3までを含めた全体の大半は自動ペネトレーションテストには適さない

また、OWASPはASVSについては認証を行っていない、ということを文書内で表明しています。
これに加え、ASVSの中には厳密に書かれているわけではない検証要件もあり、ASVSに準拠しているかどうかはそれぞれの組織によって前提条件なども踏まえて判断する必要があります。

なお上記に挙げた注意点は一部を抜粋したものですので、ASVS採用の際には全体を一通り確認することを推奨します。

検証要件

ここからは、14章に分類された検証要件について、カテゴリごとの概要を紹介します。レベル1では、1章を除く13章131項目が検証要件ですが、当社AeyeScanではそのうちの7章を除く12章101項目を自動で確認可能です。

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

この章では、ソフトウェア開発全体における以下のようなトピックについて広く触れています。

ドキュメント化
セキュリティに関するガイドラインやポリシーの整備
設計から実装にいたるまでの広範囲のベストプラクティス

V2:認証の検証要件

この章では、アクセスしている主体が誰であるか(または何であるか)を確認する行為である認証についての検証要件のリストを記しています。
検証要件には、単純に正しく認証できること(なりすましを防ぐ)だけでなく、パスワードの漏洩を防ぐための仕組みや強固なパスワードを設定するようにユーザに求めるといった要件も含まれます。

V3: セッション管理の検証要件

セッション管理の検証要件には、セッションが各個人に固有であることや、不要になったタイミングで無効にすることなどの一般的なベストプラクティスが含まれています。
また、クッキーベースのセッション管理やステートレスなセッショントークンによるセッション管理など、実装方法に固有の要件もあります。

V4: アクセス制御検証要件

この章は、認可に関する検証要件から成り立っています。
一般的な権限チェックなどのアクセス制御に関する要件だけでなく、管理用インタフェースにおける適切な多要素認証の使用や、ディレクトリリスティングへの対処など個別のケースについても言及されています。

V5: バリデーション、無害化とエンコーディング検証要件

この章は外部からの入力の処理に関する章であり、XSSからバッファオーバーフローにいたるまで広範な攻撃に関する検証要件について触れています。
他の章にも同様のことが言えますが、検証項目によっては、 "ホワイトリストを使用することで、アプリケーションがSSRF攻撃から保護されている(5.2.6から抜粋)" のように具体的に書かれているものもある一方で、 "アプリケーションが、リモートファイルインクルードやローカルファイルインクルードの影響を受けない" のように、対策すべき攻撃手法だけ書いてあるものもあるため、具体的にどう対処すべきか、またどう確認すべきかについては個別に調査が必要です。

V6: 保存時の暗号化の検証要件

暗号化にまつわる検証要件の章です。
個人を特定できる情報(personally identifiable information = PII)など、暗号化すべきデータが暗号化されていること、暗号化に使用するアルゴリズムやシークレット管理などに関する項目があります。
また、一部のセクション(V6.2, V6.4)では開発者はレベル1に含まれていない検証要件であっても必須と考えるべき、と書かれているため、ASVSの利用の際には各セクションを確認するようにしてください。

V7: エラー処理およびログ記録の要件

この章の目的は、ユーザと開発者双方にとって有用な情報を提供するようなエラー処理やロギングを作ること、逆に個人情報や機密性の高いデータを必要ない限り記録せず、外部への開示を防ぐことです。この章では、エラー処理およびロギングにまつわる以下のような検証要件がまとめられています。

詳細な調査に役立つ適切な情報を含むこと
クレデンシャルなど不適切な情報を含まないこと
ログが不正アクセスや改ざんから保護されていること
エラー発生時にはメッセージと共にサポート担当者の調査に利用可能なユニークなIDを表示すること

V8: データ保護の要件

この章には、機密性、完全性、可用性それぞれの観点から適切なデータ保護を行うための検証要件が含まれています。
また、個人情報の扱いに関するポリシーがユーザに対して示されていることや、利用に関しては同意を取ることなど、開発者だけでなく組織全体で認識すべき項目もあります。

V9: 通信の検証要件

ユーザによる通常のサービス利用、開発者によるSSHや各種管理ツールなど、あらゆる通信のセキュリティを確保するための検証要件です。
外部からの通信だけでなくDBへの接続など内部通信であっても、第三者の傍受へのに対しても対策として通信の適切な暗号化が求められています。

V10: 悪意のあるコードの検証要件

この章では、コードを対象とした以下のような項目がリスト化されています。

悪意のある挙動の影響を限定的にするための様々なベストプラクティス
バックドアにつながるコードが含まれていないこと(アカウントのハードコードや悪意を持って使用可能な隠し機能など)
悪意のあるコードを発見するためのコードチェック観点

V11: ビジネスロジックの検証要件

この章では、ビジネスロジックに対する攻撃の対策などの要件が記述されています。
また、ビジネスロジックはアプリケーションごとに固有な要素であるため、個別に脅威モデリングなどの方法でリスクを特定して対策することも検証要件として含まれています。

V12: ファイルとリソースの検証要件

この章は、アップロードされたファイルの扱いやファイルダウンロード処理における検証要件から成り立っています。
外部からの入力として適切に処理するという以外に、拡張子に関する注意点やファイルサイズの上限など、ファイルを扱う処理固有の観点が書かれています。

V13: API、Webサービスの検証要件

アプリケーションがAPIを使用して他の処理を呼び出す際の検証要件が定義されています。この章では、JSONやXML、GraphQLが一般的な例として挙げられています。

V14: 構成の検証要件

この章では、アプリケーションコードの設計や実装だけでなく、ビルドパイプラインや依存関係の管理などアプリケーションの開発に関わる広い要素について言及しています。
構成管理やCI/CDによる自動化など、セキュリティ以外の面からも効果が認められている手法についての項目も多く含まれています。
また、HSTSなどセキュリティに関するHTTPヘッダの検証要件も含まれており、Webアプリケーション開発における一般的なチェックリストとしても役立ちます。

まとめ

今回はOWASP ASVSについて紹介しました。それぞれの項目についてはあくまで概要レベルの紹介となりましたが、Webアプリケーションのセキュリティチェックリストとしてだけでなく、ベストプラクティス集としても価値がある文書のため一度読んでみることを推奨します。

AeyeScanについて

エーアイセキュリティラボはASVSの普及を推進しており、ASVSの各項目を確認するための機能をAeyeScanに実装しています。
執筆時点では、ASVS4.0.1 レベル1の検証項目131のうち101項目を自動で確認することが可能です。

AeyeScanのトライアル、脆弱性診断の自動化のご相談はこちら

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up