開発者やプロダクトオーナーにとって、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