※資料は最下部にあります。
前回は紹介だけでしたが、
今回から内容の解説をしていこうと思います。
以下の形式で解説していきます。
・V1、V2などは資料内のシート名
・基本的にレベル１（シート内でカラム「1」に「○」）のものを対象（例外あり）
・まだ勉強中のためあやふやな部分あり
今回はV1とV2の途中まで（数が多いため）を解説します。
V1に関しては「基本設計フェーズ～」の段階のため、
かなりあやふやです。（実務経験が少ない）
V1：アーキテクチャ，設計，脅威モデリング
設計段階からのセキュリティ観点
「アプリケーションのコンプリートガイドはありますか？」みたいな感じだと思います。
No.1 アプリケーションのすべての構成要素を把握し，それらが必要とされている
「自分たちが作るアプリケーションなんだからすべての機能知ってるよね？」だと思います。
すべてのフロー、機能などを完璧に理解することは難しいですが、
そこさえ理解していればテスト観点の網羅性、「リリース後の処理追加」による脆弱性は生まれにくい。
V2：認証に関する検証要件
ログイン回りや要認証ページなどのセキュリティ観点
アプリケーションの入り口となるところなので最重要。
No.1 意図して公開しているものを除き，すべてのページとリソースがデフォルトで認証を必要とする（完全仲介の原則）
本資料の2.1.設計原則 3.Complete mediationを参照
No.2 すべてのパスワードフィールドについて，ユーザが入力したパスワードがそのまま表示されない
htmlのinput type="password"で解決
パスワードをどうしても表示させた場合は、
JSなどで制御するといいでしょう。
No.3 すべての認証がサーバ側で行われる
フロントエンドで出来ることはできますが…
これは必ずサーバーサイドで実装しましよう。
No.4 すべての認証機構がフェイルセキュアであり，攻撃者がログインできない
フィルセキュアとは
…らしいです。（初耳でした）
まずは、悪意ある人間がログインできないことが大前提ですね。
豆まきと一緒です。
フィルセキュアが認証機構は各種フレームワークで実装するのが一番だと思っています。
独自機構では、漏れが出る可能性が高いので（FWでもバージョンにより脆弱性はありますが…）
No.5 パスワード入力フィールドでパスフレーズの使用を許可または推奨し，長いパスフレーズや複雑なパスワードの入力を拒否しない
パスフレーズとは
パスワードはなるべくなら「大文字小文字英数字記号」を必須とするといいでしょう。
V2の続きは次回で～
▼▽▼▽▼▽▼▽▼▽▼▽▼▽▼▽▼▽▼▽▼▽
ASVS 3.0.1まとめ - Google スプレッドシート
▲△▲△▲△▲△▲△▲△▲△▲△▲△▲△▲△