開発者やプロダクトオーナーにとって、Web アプリケーションが事故を起こさないようにセキュリティを確保することは重要な関心ごとだと思います。

しかしながら、セキュリティを考えたときに、多くの懸念事項や実装上の考慮事項が思い浮かび、一見すると際限がないことを考えているように感じてしまうことがあるかもしれません。

また、すべてを完璧に行うことが現実的ではない中、何をどこまでやるべきか判断することは難しいことだと思います。

今回は、上記のような課題を解決するときに参考になるドキュメント「OWASP Application Security Verification Standard 4.0（以下、ASVS）」を yamory の視点で紹介したいと思います。

この記事が、セキュリティ要件の策定や要件の見直しを検討する際の参考に少しでもなれば嬉しいです。

なお、本記事は OWASP の公式見解ではありません。

ASVS とは

ASVS は、OWASP が策定した 286 項目の要求事項から成る Web アプリケーションに関する網羅的なセキュリティ要件のリストです。
言い換えると、セキュアな Web アプリケーションとは何かを定義したリストだと言えます。

著名なプロフェッショナルを含む世界中のエンジニアが GitHub を用いてオープンなプロセスの下に作成された、Web アプリケーションに関する網羅的かつ信頼性の高い唯一のセキュリティガイドラインです。

全体を通して、セキュリティ要件をテストするエンジニア向けに書かれていますが、開発者としても実装要否の判断や、実装すべき機能のリストとして利用できます。

アプリケーションの特性に応じたセキュリティレベル

ASVS の特徴として、アプリケーションの特性に応じて準拠すべきレベルを三段階に分けて定義されています。
これにより、自分のアプリケーションが最大で何を満たさなければいけないかを把握することができます。

ASVS には何が書かれているのか

ASVS は、合計 14 の章で構成されています。
今回の記事では、各章に関する詳細な説明を割愛しますが、大まかな各章の概要を紹介します。
多くの章があり、かなり網羅的なガイドラインであることを感じていただけるかと思います。

V1: アーキテクチャ、設計、脅威モデリングに関する要件 (Architecture, Design and Threat Modeling Requirements)

開発プロセスに入る前にセキュリティ観点での計画を促すことを目的に「全体のアーキテクチャに関わること」「管理体制」が言及されています。
セキュアなアプリケーションを開発する上での骨子を作成するための章とも言えます。

この章のみ Level2 以上を対象としていますが、開発方針で意識した方が良いことなどが定義されており、非常に参考になる情報が多いです。
そのため、Level1 を目標にされる方も Level2, 3 を一読されることをお勧めします。

V2: 認証に関する要件 (Authentication Verification Requirements)

数億のユーザ名やパスワードが漏洩し、既存のユーザ名とパスワードを用いた管理施策が困難になってきている状況を踏まえ、今後実装すべき要件が定義されています。

認証に関して最良の基準とされている NIST SP800-63B へのマッピングも行われており、強度の高い認証を実現する上でとても参考になる情報が掲載されています。

V3: セッション管理に関する要件 (Session Management Verification Requirements)

セッション管理に関する要求事項を定めた章です。

この章の特徴として、近年のマイクロサービスの普及を考慮してか、Cookie によるセッション管理だけではなく、JWT、API キーを用いたセッション管理のセキュリティ要件も定義されています。

V4: アクセスコントロールに関する要件 (Access Control Verification Requirements)

正当な権限を持つユーザがリソースにアクセスできるように適切なアクセス制御を行えるように定めた章です。

この章では、一般的な認可の考えかたをベースにしつつも、特殊なケースにも言及をしています。
たとえば「例外発生時のアクセス制御について」「クライアント側でのアクセス制御」「.git, .svn, .Thumbs.db, .DS_Store といったメタデータの非公開」などです。

V5: バリデーション、サニタイジング、エンコーディングに関する要件

(Validation, Sanitization and Encoding Verification Requirements)
入出力値の処理に関する要求事項を定めた章です。

SSRF や安全ではないデシアライゼーション攻撃など、近年問題となっている攻撃への対策も言及されており、必ず一読することをお勧めします。

V6: 暗号に関する要件 (Stored Cryptography Verification Requirements)

暗号で使用するアルゴリズム、鍵情報の保管方法について定めた章です。
個人情報（PII）や GDPR に関することから、暗号における脆弱性と攻撃・暗号方式・鍵の管理などが記載されています。

V7:エラーハンドリングとロギングに関する要件 (Error Handling and Logging Verification Requirements)

インシデントレスポンスや攻撃検知を前提としたログの要件、一般的にログならびにエラーハンドリングをセキュリティの観点からどのように扱えば良いのかについて定めた章です。

V8: データ保護に関する要件 (Data Protection Verification Requirements)

機密情報の保護方法や HTML5 ローカルストレージの使用などクライアント側でのデータ保護の要件を定めた章です。

機密情報の保護では近年のクラウド化や CDN などの普及を考慮してかキャッシュからの漏洩、Cookie・HTTP ヘッダからの漏洩などに言及がされています。

V9: 通信に関する要件 (Communications Verification Requirements)

クライアントとの通信、マイクロサービスを想定したサーバ間の通信に関する要件を定めた章です。
通信における強力な暗号方式の利用や、バックエンドにおけるTLS接続の失敗のロギングなどが掲載されています。

V10: 悪意のあるコードに関する要件 (Malicious Code Verification Requirements)

悪意のあるコードを作り込まない、挿入させないようにするための要件を定めた章です。

ときおり発生する OSS ライブラリなどに埋め込まれたバックドアやマイニングスクリプトといったサプライチェーン攻撃や、内部の攻撃者が埋め込むルートキット・時限爆弾などをメインのアタックベクターとした内容が記載されています。

また、一般的にセキュリティの知見を持たなければ見つけることが難しい悪意のあるコードを発見するためのレビュー観点も定義されています。

V11: ビジネスロジックに関する要件 (Business Logic Verification Requirements)

ビジネスロジックに作り込まれる脆弱性は、最も見つけにくく、開発者が一番注意を必要とする部分です。

この章では、そのような脆弱性を見つけるために持つべき視点が定義されています。
たとえばトランザクションの不整合、過剰なファイルアップロードなどが言及されています。

V12: ファイル、リソースに関する要件 (File and Resources Verification Requirements)

主に、信頼できないソースから取得したファイルの取り扱いを定めた章です。
ユーザからファイルを受け付ける Web アプリケーションの場合、必ず読むことをお勧めします。

また、ファイルインクルージョン攻撃や SSRF 攻撃を防ぐための要件が定められており、全アプリケーションで有用だと思います。

V13: APIおよびWebサービスに関する要件 (API and Web Service Verification Requirements)

API や GraphQL, SOAP など Web サービスに関して考慮すべき要件が定められています。
この章では、近年のアプリケーショントレンドをカバーする形で、セキュリティ要件や脆弱性となり得る要素について言及がされています。

V14: 構成に関する要件 (Configuration Verification Requirements)

ビルドやフレームワークでの設定にて対応すべき要件が定められています。
この章で言及される要件はとても幅広い内容となっています。

たとえば「CI / CD による安全で再現性のある実行」はもちろんのこと、「デバックモードによる意図しない漏洩」「CDN で配信するデータの改ざん検知」「サードパーティーライブラリのサンドボックス化」「HTTP セキュリティヘッダ要件」「HTTP リクエストヘッダにおけるバリデーション要件」など、さまざまな視点でのセキュリティ要件が記載されています。

ASVS を導入するべきか

OWASP Top10 などとの違い

OWASP Top 10 や OWASP Top 10 Proactive Controls について耳にしたことがある方は多いと思います。
これらと ASVS の最も大きな違いはその目的にあります。

Top10 シリーズを通じてアプリケーションのセキュリティを高めることは確かにできますが、あくまでそれらは開発者などに対する喚起であり、十分にセキュアなアプリケーションを構築することはできません。

セキュアなアプリケーションであるためには、ASVS に準じる必要があると思います。

Top10 シリーズから着手しよう

これまでに Top10 の導入などを開発現場で特に意識していない状態で、ASVS を導入することは心理的・実務的負荷も高いため、OWASP Top10、Proactive Controls の導入から検討することをお勧めします。

なお、ASVS には Proactive Controls ,Top 10 の施策も含まれており、ASVS への移行もより楽になると思います。

さいごに

OWASP ASVS 4.0 には、多くの要求事項があり、馴染みのない単語も多いため、読むだけでも非常に負荷が高いドキュメントです。

しかしながら、セキュリティに関する関心ごとが網羅的にまとまっており、アプリケーションのセキュア化を考える際にはとても助けになると思います。

次回の記事では、yamory がどのように活用の仕方を考えているのかなどをご紹介したいと思います。

参考情報

• GOTO 2018 • From the OWASP Top Ten(s) to the OWASP ASVS • Philippe De Ryck
• OWASP Application Security Verification Standard
• OWASP アプリケーションセキュリティ検証標準 4.0 日本語版
• From the OWASP Top Ten(s) to the OWASP ASVS - Jim Manico