先日日本語訳版が発表されたばかりの OWASPアプリケーション検証標準 バージョン4（以下ASVS v4)を用いて、 Webアプリケーションセキュリティの評価をサービスに対して実施した感想などについて記載します。

ASVS v4は非常に包括的なWebアプリケーションセキュリティの評価ガイドラインです。 それこそ「エンジニア研修でまず最初に読もう！」と推進したくなるほど多角的に記載がされています。

どのぐらい包括的であるかについてですが、開発体制・ログ・認証・ログインフォームの設計・総当たりに対するアカウントロックの時間・GraphQLにおけるセキュリティなど、とにかく盛りだくさんな記載がされています。

すべてのエンジニアにとって必読の ASVS v4

こんにちは、佐分基泰と申します。 16年の新卒として入社し、サーバサイド -> 脆弱性診断士を経て、 現在はOSS Libraryセキュリティサービスyamoryで開発とセキュリティエンジニアをやっています。
ちなみに本日が最終出社日となりますw

さて、改めてになりますが先日（2020/09/03）に、OWASPから出版されている「アプリケーションセキュリティ検証標準」通称OWASP ASVSのバージョン4の日本語訳版リリースされました。 日本語版は、コンピュータソフトウェア協会（CSAJ）様のSoftware ISACによる翻訳になります。

1つ前のバージョンであるASVS v3は2015年に発行され、Webアプリケーションにおけるセキュリティ標準として幅広く認知されてきました。 しかし、発行から月日が経ったため、モダンなサービスではレガシーに感じてしまう部分が複数ありました。

このASVSがアップデートされたことにより、現代のモダンWebアプリケーションのセキュリティ評価ではかなり有用に働く内容になりました。 詳しくは、私が所属している組織のサービス yamory のセキュリティブログに解説記事が記載されています。

上記を読んでいただければわかると思いますが、 今回v4になったことで、ナウいソフトウェアエンジニアは必読なドキュメントに仕上がっています。

リリースされたばかりであるため、このv4を使ってサービスのアセスメントを行っている事例は、日本国外をみてもまだそこまでない状態です（もしや国内初！?）。

そこで本記事では、今年の5月ごろにサービスに対してOWASP ASVS v4のレベル1を用いてリスク評価を行ったことについて、感想や詰まりどころを書いていきます。

※ASVS v4ではレベル1を「すべてのアプリケーションが目指すべき必要最低限のレベル」と定義しています。

評価した感想

ここまでASVS v4をベタ褒めしてきましたが、実際に評価してみて結構厄介な部分があると感じました。

以下が評価時に感じた難点です。

上記の通り「適切な評価をしよう」となると、必然的に適切な知識や時間・技術が必要になります。 例えば「XSS」に対する言及があった際に、以下のような攻撃手法や対策についてある程度認識しておく必要があるように思えました。

他にも「ログに機微情報が出ていないこと」の様な項目も、評価が難しいと感じました。
なぜなら、「機微情報たるデータがログに出ていない」と言えるまで調査をする必要があるため、根気や時間、そのサービスが抱える機微情報（に関するドメイン知識）が必要になります。

なので「厳密に」評価をする際にはそれなりな知識が必要だと思いました。 逆に言うと「厳密ではない」評価をする際や、基本設計などをする際の辞書として使うにはかなりいいドキュメントだと確信しています。

例えば近年騒がれている総当たりに関するアカウントロックの時間といった内容も含まれているため、 開発時の参考にするもよし、他の開発者や上司への説得材料としても有用に使えるはずです！

各チャプター評価の感想と評価時のコツ

ここからは、ASVS v4のレベル1を使った際に感じた「各チャプターに関する感想」などを記載します。

14章分の感想などがぎっしり詰まっているため、気になる章のみを読んでいただければと思います！

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

レベル1がない項目なので今回は未評価になります。

V2: 認証の検証要件

ここはエンジニアであれば、是非一度目を通して欲しい内容がぎっしり詰まってます。
「2020年現在のセキュア」を体現するために、結構強気に書かれている部分があります。

意訳ではありますが、例えば以下のような内容が記載されています。

この章はアメリカ国立標準技術研究所NISTの出版した認証に関するガイドラインNIST-800-63をベースにしているのもあって、 よくできている様に感じました。

例えば、近年色々と注目を浴びた総当たりに関する部分と緩和策についても複数触れられています。 他にもパスワードのストレッチング回数にも言及があります。

ストレッチング回数はマシンスペックの向上によって大きく影響を受けるため、 「OWASPという信頼できる団体が、2020年現在の必要だと言っている最低回数」という回答が得られたわけです。 これは機能設計をする際のエンジニアにとっては、指標が提供されたわけなので、嬉しいはずです。

と、べた褒めしつつもアプリの評価をする場合、 そこをチェックするためにはどうしてもコードベースの検査・外形検査が必要になります。

と調べ回らなければならないのは、なかなか辛いです。 なので、見ず知らずのサービス・経験の浅い言語のサービスなどをとっさに検査しろとなると、なかなか難しいと感じました。

ただ、その分「ここをもっと良くできそうだぞ！」といったセルフチェックが実施できました。 そのため、セキュリティ向上施策の案を出せたのもあり、非常にポジティブに作業を進められました。

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

ここに関しても「セッション時間、何時間なら安全なんだ？」という事業会社としてはよくある悩み（だと自分は思っている）部分について、 具体的な時間を提示してくれています。

また、Cookieの __Host- プレフィックスなど、（おそらく一般のエンジニアには）まだ認知されていない設定なども組み込まれています。 この辺りは、啓蒙もかねていると感じました。

一方で、一般のエンジニアからすると複雑な言葉が多数出てくるのもあって、事前知識が必要であるという敷居の高さがあるように思えました。

例えば「セッショントークンに少なくとも64ビットのエントロピーがあることを確認します。」というのが若干厄介だと感じました。

咄嗟に「あなたのサービスのセッショントークンは、64ビットのエントロピー以上か？」と問われて答えられる人はいないでしょう。 なので、Wikipediaのパスワード強度のページを参考に、 サービスで使われるセッションの長さや文字種からエントロピーがどの程度かざっくり計算するなど、面倒極まりない作業をする必要がありました。

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

ここはセキュリティに携わる人なら教科書で見る様な内容（最小権限の原則、デフォルト拒否の原則など）が多く記載されています。

特筆する点があるとすれば、 Thumbs.db, .DS_Store, git, .svn などのファイルをアップロードしてしまうことが原因の情報漏洩に関して言及している部分でしょうか。

正直なところここを少数の人間で適切にアセスメントするのは無理があります。 なので厳密にやりたい場合は「（かなりの頻度の）脆弱性診断」や「バグバウンティ」などの手法を用いて評価を行うことが必要になると思います。

リリース頻度が高い開発ほど漏れも出るため、自動化とヒューマンエラーをキャッチできる施策（脆弱性診断など）を合わせた複合的な対策がマストだと思います。

これらの「厳密な評価が難しすぎる」という背景もあり、この章の評価では 「容易に評価が実施できる部分」にフォーカスし、管理コンソール周りのチェックであったり、 DNS総当たりなど、実施しやすいもののみで評価を終えました。

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

名前の通り、入力検査や無害化などに関する部分で、Command Injection, XSS, SQLIなどの一般的な攻撃のほか、 （近年再注目されてる）SSRFの話などに触れられています。

特徴的と感じた点としては、SVGを使ったXSSの手法（スクリプトを埋め込んだ .svg ファイルをアップロードし、直接閲覧することで発生するXSS）などにも言及がある点などでしょう。

ASVS v3では、この様なエッジケースとなる攻撃手法（対策）についてはあまり触れられていない印象でしたが、 今回は特殊なケースについてもある程度触れられています。 おそらくこれらの攻撃手法が攻撃者の中では認識されてはいるものの、開発者にはまだ浸透しきっていないということでしょう。

他にもmarkdownなどが普及したことで、markdownをリッチに表示できるEditorが多く出てきており、 それらを狙ったmarkdownのXSS（コンバートミス）についても言及がありました。 これらの項目から、XSSの問題が世界的に数多く報告されていることが、改めて窺えます。

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

レベル1はPadding Oracle攻撃にのみの言及していたので、脆弱性診断やセキュリティスキャナーの検知がなかったか、といった観点で調査を進めました。

レベル2の内容からは安全な暗号方式の選定や、（GDPRなど含めた）データ分類に関する言及があります。 そのため、レベル1のチェックのみを行なっている人も、一度は目を通した方が良いのではないでしょうか。

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

ログ周りのチェックに関する部分で、レベル1の項目は少ないですが、チェックは非常に面倒でした。

（ログの集約が終わっている前提で書きますが）ログの中から「資格情報」やそれに類する情報を見つけるのはなかなか骨が折れます。

など、ログ周りは色々な情報が入りこむ余地があります。
そのため、定期的な監査の必要な部分であり、とても地味な部分です。

しかも、自動化しようにもログフォーマットがバラバラだったりと、厳しい要素が多すぎる部分でもあります。 (AWS Macie とか えーあい？というやつ が最強に検知してくれる世界になってくれることを祈ってます)

V8: データ保護の要件

キャッシュ周りの話や、個人情報の収集にまつわるポリシーの提示など、これまでとは少し別の視点で情報を見る必要がある章でした。

「データエクスポートの機能があること」など、GDPRに影響されて書かれている項目もあるため、外形的な調査だけでなく、 サービス仕様の調査なども行う必要があります。

V9: 通信の検証要件

暗号通信にまつわる部分について記載されており、 「TLS1.0, TLS 1.1はもう無効にしてますよね？」といった話や、「弱い暗号方式は使っていないよね？」といった基本的な点に言及がされてます。

この辺りも脆弱性診断で大抵見られる部分ではありつつも、暗号の強度は何処かのタイミングで 「xxxx年現在は、この暗号方式は非推奨」と、評価が変わることがあるため、定期的な評価・改善の必要になります。

V10: 悪性コードの検証要件

レベル2以降では、攻撃者となる開発者が紛れ込ませた悪性コードに関する話であったり、 悪性コードを内包したサードパーティーライブラリに関して言及があります。

レベル1の場合はそこまで突っ込んだ話はせず、アプリなどの完全性の担保や、 最近ホットなSubdomain Takeover攻撃に関する言及がされています。

この辺りも評価をする場合はある程度セキュリティの知識（とりわけ脆弱性診断やバグバウンティ系の知識）が 必要になるため、一般には評価しにくいと思えました。

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

「トランザクションが正しく制御できているか？」「TOCTOUの問題に対応しているか？」など、 「100％安全である」と証明するのは無理な項目が多くあります。

逆にいうと、どのようなサービスでも「問題が発生する可能性が大いにある」という項目です。 そのため脆弱性診断を受けて、その結果をもとに水平展開し、セキュアな開発体制・レビュー観点などを築いていくのが効率的だろうと思いました。

とはいえ、思っただけでは評価が終わりません。 そこで、今回の評価では、過去の脆弱性診断の結果などを参考に評価を進めました。

この辺りをDASTなどのツールで評価するという手法もある気はします。 しかし、現在市場に出ているDASTの殆どは、この辺りの「コンテキスト理解」であったり、 「過剰検知・検知不足の評価」という部分がまだまだ弱いのが現状です。

なので、ここに関しても技術革新が起きてくれることを切に願ってます。

V12: ファイル、リソースに関する検証要件

ZIP爆弾、Local File Include, SSRFなどのファイル・URLなどの話や、 JSONP, Reflected File Downloadなど、昔ながらの問題についても触れている章でした。

サービス規模が大きい場合、おそらくコードベースよりもアクセスログやGoogle DorksなどのOSINT技術などと合わせて 「問題のありそうな箇所」を洗い出す方が評価をしやすいと感じました。

ただ、OSINTのみで安心できるかというとそういうわけではないので、可能であれば複数の視点から調査をするのが パフォーマンスの良い評価方法だと思います。

例えば以下などの評価方法を使うことで、それなりに抜け漏れなく調べられるのではと思っています。

完全にバグバウンティや、診断の手法ですね。
この辺りはSASTなどでも担保ができる領域なので、評価よりも実装段階から弾くのが良いと感じています。

また、SSRFに関しては1つの節を使って言及しているため、まだエンジニア全体に対してこの問題が（古くからあるにも関わらず）認識されきれてないということが読み取れます。

V13: API、Webサービスに関する検証要件

RESTful APIに関して重点的な言及がされていたり、GraphQLに関しても言及があるなど、 かなりモダンWebアプリケーションを意識した部分が多いです。 例えばCSRFもステートレスなDouble Submit Cookieの対策や、Originヘッダの検証などに触れています。

このあたりの章もCSRFがバイパスできないかなど、実際に診断をしてみるしかないのが痒いところだと思いつつ、 診断ツールでぽちぽち確認を進めました。

V14: 構成に関する検証要件

最後の章ですね。ここは最も重要です！
何が重要かというと、私が所属するyamoryで解決できる領域だからです！

この章では、依存性関係チェッカーを用いて、コンポーネントの問題を解消することについて言及がなされています。

例えば、 ~OAuth　というライブラリが使われていた際に、そのライブラリが内部で ~HttpClient というのを利用していたとします。 この ~HttpClient に実は脆弱性があり、しかも攻撃コード（PoC, Exploit コード）が公開されていたらどうしましょうか？　

このような依存関係における脆弱性の問題などは、OSSを使う上で避けては通れない問題です。 是非お困りの際は、以下の問い合わせ窓口より連絡をくださいませ！
https://yamory.io/contact/

と話がそれてしまいましたが、上記の様なコンポーネントの話の他にも、JS, CSSなどの完全性の検証（SRI）などが言及されています。

この章は全体を通してコードベースの評価が多くある印象でしたが、 脆弱性DBなどを扱わないとなかなか対策が難しい部分だなと感じました。

他にも外形的な問題チェック（HTTPヘッダからの利用ライブラリのバージョン情報の露出）や、 一般的なセキュリティ系HTTP Headerの付与、CSPへの言及があります。

このあたりは脆弱性診断で指摘される内容なので過去のレポートを元に評価をサクサクできるので楽です。

ASVS v4の有用性と評価する難しさ

いかがでしたか？

ここまでの章の内容を読んで「包括的なWebセキュリティガイドラインである」ことが伝わったと思います。
また、厳密な評価は難しいものの、辞書的に扱うのに十分な情報がまとまっている強力なガイドラインであることもわかっていただけたのではないでしょうか。

本記事を読んでアセスメントしてみようと思われた方であったり、OWASP ASVS自体に興味を持っていただけた方がいらっしゃれば嬉しいです。

さて「実際問題実施してどうだったか」ですが、レベル1で3日程かかりました。そのため、レベル2, レベル3となってくると、検証などにより時間がかかると思います。

また大抵の場合は、サービス規模が大きいほど、セキュリティ要件が重い傾向にあります。 リリースしてまもないサービスだからこそ、評価が3日で済んだだけで、大きい規模となると、 もっと評価が難しくなり、情熱だけで評価し続けるのはなかなか厳しそうだなと感じてしまいました。

とはいえ、小さい会社から大きい会社まで関係なくセキュリティのリスクは存在しているため、 「自分自身（会社自身）がどれだけセキュリティを高めていくのか」という意識が大切だと自分は思っています。

そういった意味でも、現在の組織・サービスのセキュリティ評価を様々な角度から評価し、 問題を炙り出せるASVS v4は、相当良いドキュメントであると感じました。

また、実施した内容について、公開できる範囲の情報に触れてきました。 ただ、今回実施した内容はあくまで「評価」であり、セキュリティのゴールではありません。

アセスメントはあくまできっかけであり、より良いセキュリティを実装していくには 継続的なセキュリティ向上や、それらを支える組織文化が必要になると考えています。

仮にこの記事でASVS v4に興味を持った方がいらっしゃいましたら、是非ご自身でサービスを評価してみると良いかもしれません。 そういった情熱を持った人が増えていけば、インターネットセキュリティがより良い方向に進んでいくと信じています。 なので、まずはレッツトライ！

以上、とても長い文章になりましたが、読んでいただきましてありがとうございます。 それとOSSライブラリのセキュリティサービス yamory を是非よろしくお願いします。

佐分基泰
佐分基泰

プログレッシブデスメタルが好きです