今年もBuildのシーズンがやってきた

こんにちは、富士榮です。

今年もBuildのシーズンですね。

https://build.microsoft.com/en-US/home

今年もシアトルでの対面とオンラインのハイブリッド開催のようです。しかし昨年もそうだったんですが、今年もセキュリティやアイデンティティ系のセッションは殆どがIn person（対面）のみ、かつレコーディングもされないという悲しい感じです。

ざっくりセキュリティ、アイデンティティで絞り込むとこのくらいのセッションが出てきます。（少ないですね・・・）

code	title	type	date	time	description
DEM764	Combatting fraud with real time identity verification	in person	5/23	3:45 AM - 4:00 AM	Anyone can identify a bicycle or count stop lights. How do we know our apps are serving the right users? CAPTCHAs do not work. Introducing Face Check using Microsoft Entra Verified ID: reduce sign-up friction, the risk of fraud and account takeover. Face Check enables apps to perform real time biometric match against identity documents issued by government (e.g. driver's license or passports) or businesses and education institutions.
-	On-Demand: Boost your app security with real time biometric authentica	in person	on-demand		Integrate simple-to-use APIs to upgrade your mobile, web or desktop apps with high-assurance identity verification to reduce friction and risk from account takeover and impersonation.
DEM760	Create secure applications in minutes with VS Code and External ID	in person	5/22	3:30 AM - 3:45 AM	Learn how to use the Microsoft Entra External ID extension for Visual Studio Code to create your first External ID application completely within your IDE. Bootstrap your development with pre-configured sample applications to quickly get you started.
DEM768	Create pixel perfect authentication experiences for native mobile apps	in person	5/24	4:45 AM - 5:00 AM	The Authentication API and SDK in External ID allow developers to create pixel perfect UX for sign in and sign up experiences in their mobile applications. Join our product experts to explore the APIs and SDKs for Microsoft Entra External ID that give you the control and flexibility to create fully custom and secure login experiences on mobile devices.
-	True zero-trust runtime security in AKS	online	on-demand		NeuVector is open source, container native and can make your containerized workloads more secure… today! See first hand how to get to true zero-trust runtime security in AKS and other Kubernetes deployments with NeuVector by SUSE. We will take an application through its deployment lifecycle, from Dev/Test to Q/A to Production, and automate the 'fingerprint" of appropriate behaviors in your software stack. Join us for this real-world example of how to not just identify attacks but to actually prevent them.
DEM766	Simple and secure app authentication with authentication brokers	in person	5/23	6:45 AM - 7:00 AM	We delve into the integration of Web Account Manager (WAM) on Windows through various MSAL libraries such as MSAL.NET, MSAL Python, and MSAL Java. The session will highlight the seamless authentication experiences enabled by WAM, which simplifies account management on Windows devices. We’ll explore how MSAL libraries facilitate public client authentication flows with Microsoft Entra ID, enhancing web, mobile, and desktop applications.
DEMFP867	Unleash the power of network APIs	in person	5/24	7:45 AM - 8:00 AM	Learn how you can leverage the advanced capabilities of telecom operator networks through APIs to enhance your applications. This session will cover GSMA Open Gateway and CAMARA, examples of how mobile operators are working with developers to open up network APIs, and how developers can engage via Microsoft’s platform and services with Azure Programmable Connectivity (APC). We will also showcase a demo mobile app using the network's APIs through APC and show the code on how to develop with it.

個人的に興味があるのは、１行目のCombatting fraud with real time identity verificationと最後の行のUnleash the power of network APIsくらいでしょうか。前者はEntra Verified IDとfacecheckの話です。後者はMicrosoftのイベントでは結構珍しくネットワークキャリアを対象としておりGSMAやCAMARAの話なんかをカバーしているっぽいので聞いてみたいですね。

レコーディングもされませんし配信もされないので聞けませんが・・・（残念）

OAuth2.0 Security Best Current Practiceを読んでみる（８）

こんにちは、富士榮です。

ようやくこのシリーズも終わりです。

引き続き攻撃パターンと緩和策です。最後の3つを読んでいきます。

攻撃パターンと緩和策

• クリックジャック
• 認可エンドポイントにアクセスした時に表示する画面に透明なiFrameを仕込むなどのクリックジャックの話です
• 認可エンドポイントはMUSTとしてクリックジャック対策をしなければなりません
• W3CのContent Security Policy Level2以上を適用すべきです
• こんな風にする感じですね

HTTP/1.1 200 OK

Content-Security-Policy: frame-ancestors https://ext.example.org:8000

Content-Security-Policy: script-src 'self'

X-Frame-Options: ALLOW-FROM https://ext.example.org:8000

• 認可サーバがフィッシングサイトにリダイレクトする
• 前も出てきたかもしれませんが、正しくredirect_uriが設定されていたとしても攻撃者によってフィッシングサイトに誘導されてしまう可能性はあります。
• 例えば、無効なスコープの値を指定することでフィッシングサイトへ誘導するケースや、有効出会っても攻撃者によってコントロールされたclient_id、redirect_uriを使った誘導（同意拒否をしても誘導される。他にもprompt=noneで誘導する）ケースがあげられています
• 認可サーバでこれらを防ぐためにはprompt=noneのケースをのぞき、必要に応じてユーザ認証を行う必要があります
• また、リスクに応じて追加のアクションを講じるのも一つの手段です
• 基本的にredirect_uriが信頼できない状況ではリダイレクトするべきではありませんが、信頼できない場合にユーザがリダイレクトするかしないかの判断をするような実装を行なっても良い（MAY）ということです
• ブラウザ内の通信フローに対する攻撃
• 認証応答がリダイレクトではなくpostMessageなどで送信されるケースにおいて悪意のある通信先に対して通信が行われるケースがあります
• 例えば、送信先の制限が不十分な実装をするケースなどが挙げられています。ワイルドカードで送信先が設定されていますね

window.opener.postMessage(

  {

    code: "ABC",

    state: "123"

  },

  "*" // any website in the opener window can receive the message

)

• 他にも送信先のURIの検証が不十分で攻撃者の設定した値になってしまったり、送信元の検証が不十分なケースも想定されるのでURI検証やCSRF対策はしっかりとしておく必要があります
• その意味で推奨される実装としては、
• 明確なクライアントオリジンを示す

window.opener.postMessage(

  {

    code: "ABC",

    state: "123"

  },

  "https://client.example" // use explicit client origin

)

• メッセージのバリデーションを行う

window.addEventListener("message", (e) => {

  // validate exact authorization server origin

  if (e.origin === "https://honest.as.example") {

    // process e.data.code and e.data.state

  }

})

• といった実装が必要となります

ということで、ようやくこれで最後まで読みました。

実装する暇がなかなか取れませんが、徐々にやっていきたいと思います。

OAuth2.0 Security Best Current Practiceを読んでみる（７）

こんにちは、富士榮です。

すこし空きましたがこちらも続けていきます。

引き続き攻撃パターンと緩和策です。前回は307リダイレクトまで行きましたので続き13個目/18個のTLSを終端するリバースプロキシから行きたいと思います。

攻撃パターンと緩和策

• TLSを終端するリバースプロキシ
• 一般的なWebサーバの構成だとリバースプロキシ（と言うよりもロードバランサーでやることが多いかと）でTLSの終端処理をした上で実際のWebサーバへリクエストをディスパッチすることが多いと思います
• その際にhttpヘッダーにIPアドレスや証明書とのバインディングの情報などさまざまな情報を付与することがありますが、不正にヘッダを改竄することが攻撃につながる可能性があります（典型的にはX-Forwarded-Forなど）
• と言うことでちゃんとhttpヘッダのサニタイズをしましょう（MUST）ということです
• また、リバースプロキシと実際のWebサーバの間のネットワークに攻撃者がアクセスできてしまった場合を仮定して内部ネットワークにおいてもアクセス制御をちゃんとしましょう
• リフレッシュトークンの保護
• リフレッシュトークンを使うとアクセストークンが発行できるので、攻撃者にとってはリフレッシュトークンは確かに魅力的な攻撃対象です
• RFC6749でも転送中や保存中の保護やクライアント認証の実施などの対策を示していますが、ここでは更に高度な保護の方法について考えます
• クライアントのリスク評価を行った上でリフレッシュトークンの発行の可否を判断する必要があります（MUST）。リフレッシュトークンを発行しない場合は認可コードフローなどでアクセストークンを発行するように構成することができます
• リフレッシュトークンを発行する際はユーザの同意に基づき、特定のスコープ・リソースサーバへ紐付けられる必要があります（MUST）
• コンフィデンシャルクライアントの場合はクライアント認証を必須としていますが、パブリッククライアントの場合はmTLS（RFC8705）やDPoP（RFC9449）を使ってリフレッシュトークンとクライアントのインスタンスを紐づける必要があります
• ローテーションを行って無効にされたリフレッシュトークンも認可サーバは保持しておき、万一不正なクライアントが古いリフレッシュトークンを使おうと試みた場合は古いリフレッシュトークンだけでなく、アクティブなリフレッシュトークンについても無効化するなど予防措置を講じることもできます
• リフレッシュトークンに紐づくスコープの情報をトークンに埋め込むことで認可サーバは取消対象となるリフレッシュトークンの判別をしやすくなる可能性もあります
• その場合はデジタル署名を施すなどトークン自体の改竄を防ぐメカニズムも導入する必要があります（MUST）
• また、パスワード変更やログアウトなどのイベントをトリガーにリフレッシュトークンを無効化することも検討しても良いと思います
• 通常リフレッシュトークンには有効期限をつけますが、一律で設定しても良いですし、リスクレベルに応じて変更するなどの工夫をしても良いと思います
• リソースオーナーになりすましたクライアント
• 認可サーバがclient_credentialsフローをサポートする場合、アクセストークンの発行対象がユーザなのかクライアントなのかを判別することが難しくなるケースがあります
• 具体的にはクライアント登録を行う際にクライアントIDを任意に決定できる場合、ユーザの識別子（sub）と同じ値をクライアントIDとして登録することで、リソースサーバが当該のアクセストークンがユーザに対して発行されたのかクライアントに対して発行されたのかを混同してしまい、望まぬクライアントがユーザのリソースにアクセスできてしまう可能性があります
• このことを避けるためにはユーザの識別子とクライアントIDの名前空間を分離して識別可能にしたり、他のプロパティを使ってトークンの発行対象がユーザなのかクライアントなのかを判別できるようにしないといけません

ということで今回はここまでです。

しかし読めば読むほど本当にそんな実装してる認可サーバあるの？？って思いますが、こういう形でちゃんと文章として出すことが大切なんだろうなぁ、、と思っています。

OAuth2.0 Security Best Current Practiceを読んでみる（６）

 こんにちは、富士榮です。

すこし空きましたがこちらも続けていきます。

引き続き攻撃パターンと緩和策です。前回はリソースサーバでのアクセストークンの漏洩まで行きましたので続き10個目/18個の盗まれたアクセストークンの悪用から行きたいと思います。

攻撃パターンと緩和策

• 盗まれたアクセストークンの悪用
• これはすでに手遅れ？そもそも攻撃なのか？という感じもしますが、万一アクセストークンが盗まれてしまったとしても被害を最小限に食い止める努力は必要です
• 基本は送信者制限（Sender Constraint Token）と対象者制限（Audience Restriction）をすべきであるっていう話です
• 送信者制限（Sender Constraint Token）はその名前の通り、特定の送信者から送信されたアクセストークンのみをリソースサーバが受け付けるようにする、ということです。これはいわゆるべアラ（Bearer）トークンとは対称となる概念ですね
• 参考）Bearer Tokenとは？
• 方式としてはmTLS（RFC8705）とDPoP（RFC9449）があります
• どちらの方式にしても鍵を使ったトークンとのバインディングをするので当たり前ですが秘密鍵の保護は大切です
• 対象者制限（Audience Restriction）もその名前の通り、特定のリソースサーバでのみアクセストークンが利用できるように制限を行います
• こちらもアクセストークンが万一漏洩したとしても影響範囲を最小化するための対策です
• 対象となるリソースサーバを表現するためにはURLなどを利用し、アクセストークン要求時のURLと実際のリソースサーバのURLの値が異なることを検知することによりフィッシング等で作成されたアクセストークンが利用されることを防ぎます
• リソースを指定するにはRFC8707のresourceパラメータを使ったり、scopeにリソースに関する情報を埋め込むことも可能です
• そしてこちらもmTLS（RFC8705）による対策も有効です
• なお、対象者制限付きのアクセストークンを使うと、リソースサーバ単位で特化したアクセストークンを生成することができるので、機能的にもプライバシーの面でもメリットがあります。
• なお、追加の議論として認可サーバがアクセストークンをどこであれば安全に利用できるのか？という情報を提供することもできますが注意しなければならないことが指摘されています
• 一つはメタデータで公開する方法ですが、既知のリソースサーバの情報を公開してしまうことになりますし、メタデータの標準ではありません
• もう一つはトークンレスポンスの中でリソースサーバのURIを合わせて送信するパターンがありますが、正規のリソースサーバへのレスポンスならそれでいいですが、偽造されたリソースサーバへ正規のリソースサーバのURIを送っても何の検証も期待できない面で微妙です
• オープンリダイレクト
• クライアント、認可サーバの両方の構成要素がオープンリダイレクトを引き起こしてしまう可能性があるので注意が必要です
• クライアントがアクセス元となっている画面やページを記憶しておいてトークン取得後にコールバックURIから元のページへ戻す、という実装は一般的ですが、このリダイレクト機能の実装を行う際にオープンリダイレクトを許可してしまう実装にならないように注意する必要があります
• 認可サーバは仕組み上リダイレクトを行うので、こちらも実装する上でオープンリダイレクトにならないように注意が必要です
• 基本的にはRFC6749で正しいredirect_uriのみを受け付けてオープンリダイレクトを行わないことがMUSTとして規定されていますが、正しいredirect_uriを使った攻撃パターンも存在するので十分に注意が必要です
• 例えば、動的クライアント登録を行う際の攻撃パターンとしてこのようなものが紹介されています
• 無効なスコープを指定するなどしてフィッシングサイト等にリダイレクトさせるように誘導（エラーの際にどこに戻すのか？が結構重要なポイントになりますね。変なリクエストが来たからと言って指定されたredirect_uriに戻しちゃうとこう言うことが起きるのかと）
• 有効な認可リクエストを送信、この際にredirect_uriは攻撃者の制御の元にあるURLを利用する。ユーザ認証の後、属性提供同意画面でユーザが拒否をしたとしてもredirect_uri（フィッシングサイト）へ戻される
• この状態でprompt=noneでサイレントログインをするとフィッシングサイトへリダイレクトされてしまう
• 難しい問題だと思いますが、ユーザをリダイレクトする前にちゃんとユーザを認証する、redirect_uriをちゃんと信頼できるかどうか検証する、など考えないといけません
• 307 リダイレクト
• 通常のリダイレクトはGETリクエストのみについてリダイレクトする302を使うと思いますが、代わりに307を使ってしまうとPOSTリクエストについてもリダイレクトしてしまいます。
• 通常認可サーバに対するリクエストを受けるとユーザは認証行為を行うわけですが、その際クレデンシャル情報をPOSTすることになることが多いと思います。ここで307を使ってしまうと意図せずにクレデンシャル情報が別のサーバへ転送されてしまうので307を使うべきではありません

まだまだ続きます（長い）。

とは言え、実装していかないとここの対策についてイメージがわかないと思うので、一通り眺めたら実装にしつつ確認していきたいと思います。

OAuth2.0 Security Best Current Practiceを読んでみる（３）

こんにちは、富士榮です。

前回、前々回とOAuth2.0 Security Best Current Practiceについてみてきました。

今回は攻撃パターンと緩和策についてみていきます。18パターンも定義されているので今回は最初の3つを紹介していきます。

攻撃パターンと緩和策

このセクションでは攻撃ごとに緩和策が記載されています。ここまでのベストプラクティス、攻撃モデルを考慮して、自身の実装を分析し該当する攻撃パターンが当てはまる可能性があるなら緩和策を考える、という使い方になると思います。

• redirect_uriの検証が不十分
• 基本は完全一致を検証することになりますが、パターンマッチングのロジックによってはエンコードされた値などをうまくハンドリングできていないケースなどもあり得そうです。
• 認可コードグラント
• redirect_uriにワイルドカードを使うケースが主に取り上げられています。
• 例えば、「https://*.somesite.example/*」という値がredirect_uriとして登録されていた場合、「https://attacker.example/.somesite.example」も通してしまう可能性があります
• また、CNAMEレコードのメンテナンスについても言及されています。使われていないCNAMEレコードのポイント先のURLを攻撃者が取得することで意図しないredirect_uriへ誘導されてしまう可能性があります
• インプリシットグラント
• 認可コードグラントで述べた攻撃はインプリシットでも同様に発生する可能性があります
• さらにインプリシットの場合、Locationヘッダにフラグメントがついていない場合、フラグメントを再付与してしまう問題により被害を大きくする可能性があります。例えばオープンリダイレクトにより転送された先にアクセストークンを付与してしまうことで攻撃者が用意した転送先にアクセストークンを直接的に送信してしまうことが発生します
• 緩和策
• これはシンプルにredirect_uriの完全一致を確認する、につきます
• ※localhostの場合を除きますが
• リファラーヘッダーを介した資格情報の漏洩
• 認可コード、stateパラメータ、さらにインプリシットの場合はフラグメントに設定されるアクセストークンが認可リクエスト・認可レスポンスのURIの内容に含まれることからリファラーヘッダを介して攻撃者に情報が知られてしまう可能性があります
• OAuthクライアントからの漏洩
• 通常OAuthクライアントは認可サーバからの認可レスポンスを受け取るとクライアント側の画面をレンダリングする訳ですが、そのページ上に例えば攻撃者のページがリンクとして存在していて強制クリックさせたり、iFrame内の広告などとして埋め込まれていると、リファラーヘッダーを介して認可コード、state、場合によってはアクセストークンなどが意図せずに漏洩します
• 認可サーバからの漏洩
• 認可サーバから漏れるような状態になっているとどうしようもない気もしますが、上記と同じように攻撃者のサイトへ誘導される仕組みがあると資格情報が漏洩します
• 漏洩の結果として、認可コードによるアクセストークンの取得や、アクセストークンそのものの搾取による攻撃が成立してしまいます
• 緩和策
• OAuthの認可レスポンスの結果レンダリングされるページや、認可エンドポイントにサードパーティのリソースや外部サイトへのリンクを含まないようにする（まぁ、当たり前ですがたまに認可エンドポイントに広告載せたい事業者とかGAタグを埋め込む事業者いますよね・・・）
• さらに安全にするには、
• リファラーヘッダを抑制するリファラーポリシーを適用する
• 認可コードグラントを利用する（インプリシットを使わない）
• PKCEを使う
• 認可コードは一度限りの利用にする（トークンエンドポイントに渡された段階で無効化する）
• stateを一度限りの利用にする（リダイレクト先で評価された段階で無効化する）
• 認可レスポンスをリダイレクトではなくform_postを利用する（repsonse_modeパラメータ）
• ブラウザ履歴による資格情報の漏洩
• 上記のリファラーヘッダと類似ですが、認可コードやアクセストークンがブラウザの履歴に残るケースが考えられます（これ、攻撃ではありませんがログイン画面をブックマークしちゃう人もいるんですよね・・・）
• 認可コード
• redirect_uriへの認可レスポンスが履歴に残るとcode=xxxの部分も残ってしまうことがあり、この認可コードを再利用されることがあります
• 対策としては、リファラーヘッダのケースと類似ですが、
• 認可コードを一度限りの利用にする
• response_modeとしてform_postを利用する
• となります
• アクセストークン
• こちらも前述のものと同じですが、フラグメントだけでなくクエリパラメータでアクセストークンを渡すケースがあり、ブラウザ履歴に情報の残ることがあります
• 対策としては、
• クエリパラメータでアクセストークンを渡さない
• response_modeとしてform_postを利用する
• となります

とりあえず今回はここまでです。

当たり前に聞こえますが広告とかGAタグは割と普通に実装されている気がするので十分に注意しましょう。

OAuth2.0 Security Best Current Practiceを読んでみる（２）

こんにちは、富士榮です。

前回に続き、OAuth2.0 Security Best Current Practiceを読んでいきます。

今回は2つ目のブロックである「攻撃モデルの更新」です。今回は短めです。

攻撃モデルの更新

RFC6819に定義されている攻撃モデルの最新化しているセクションです。ここで定義された攻撃モデルに対して次のセクションで緩和策が定義される、という流れになっています。

定義されているのは、以下の5つのモデルです。

• A1）攻撃者がブラウザやサーバに任意のエンドポイントをセットアップできる環境にあるケース
• まぁ正直これができる環境だともう何も信じられなくなりますが、攻撃者はユーザを独自の認可サーバに誘導したり、認可コードやトークンの搾取ができてしまう可能性を考慮する必要があります。
• A2）通信ネットワークを完全に制圧されているケース
• これも当然ですが盗聴やなりすましが容易にできてしまう可能性を考慮する必要があります。
• A3）認可レスポンスを攻撃者が見れてしまうケース
• レスポンスの改ざんはできなくても見られてしまうケースは想定しておかないといけません。オープンリダイレクタなどが典型ですね。
• A4）同様に認可リクエストを攻撃者が見れてしまうケース
• リクエストが漏えいすることで攻撃者に情報を与えてしまう、というのはよくあることですね。
• A5）アクセストークンを攻撃者が取得できてしまうケース
• リソースサーバが攻撃者によって侵害されてしまっているケースなどが考えられますね。

これらの攻撃モデルのうち、A3〜A5は通常A1もしくはA2と同時に発生します。また、ここは大切なポイントだと思いますが「複数の攻撃者が協力して攻撃する可能性」についても考慮しておく必要がるとも述べられています。

次回は最終回、攻撃パターンと緩和策について読んでいきたいと思います。

OAuth2.0 Security Best Current Practiceを読んでみる（１）

こんにちは、富士榮です。

昨日ポストした通り、OAuth2.0 Security Best Current PracticeがLast Callの段階に進みました。2024年2月22日までのレビュー期間を経て正式にRFCに向けたステップに進みます。

ということで少しだけこのドキュメントを見ていきたいと思います。

何に関するドキュメントなのか

Abstract、Introductionを軽く要約すると、

• 対象はRFC6749（The OAuth 2.0 Authorization Framework）、RFC6750（The OAuth 2.0 Authorization Framework: Bearer Token Usage）、そしてRFC6819（OAuth 2.0 Threat Model and Security Considerations）の3点
• OAuth2.0のフレームワークの活用が進むにつれ、当初想定していた以上に重要なシナリオ（金融やヘルスケア、行政サービスなど）でも利用されるようになってきた
• 当然さまざまな攻撃パターンも編み出されてきており、基本的にはRFC6819により対応してきてはいるが継続的に対応していくことが重要となってきている
• そのため、このドキュメントでは最新のセキュリティ上の推奨事項を提供する

ということになっています。

文章の構造

目次を眺めると、

• ベストプラクティス
• 攻撃モデルの更新
• 攻撃パターンと緩和策

という形になっています。

まずはベストプラクティスに従いアーキテクチャを設計を行い、RFC6819発行時点に加えて最新化された攻撃モデルを念頭に置きつつ、各攻撃パターンに対する緩和策を実装していく、という流れでシステム化を進めていく、という使い方が想定されているのだと思います。

今回はベストプラクティスの部分を見ておきましょう。

ベストプラクティス

以下のベストプラクティスが定義されています。

• リダイレクトベースのフローの保護
• 全体
• オープンリダイレクト対策として登録済みredirect_uriとの完全一致を検証すること
• CSRF対策をすること。PKCEやstateですね
• Mix up攻撃に対策すること
• 資格情報を含む情報をリダイレクトする際は誤って転送しないようにすること
• 認可コードグラントの場合
• 認可コードインジェクション対策を行うこと。PKCEですね
• インプリシットグラントの場合
• トークン漏えい対策をしない限りは使わないこと
• トークンリプレイ対策
• アクセストークン
• DPoP、mTLSなどの送信者制限トークンを利用すること
• リフレッシュトークン
• パブリッククライアントの場合は送信者制限を行うかローテーションを行うこと
• アクセストークンの権限の制限
• 必要最低限の権限に絞ること
• 特定のリソースサーバで利用するようにAudienceを絞ること
• リソースオーナーパスワードクレデンシャルグラント
• 利用してはならない
• クライアント認証
• 可能な限りクライアント認証を実装すること
• mTLSやprivate_key_jwtなどを用いることを推奨
• その他
• RFC8414のOAuth Authorization Server Metadataを使うことは有用であるため認可サーバはメタデータを公開することを推奨
• リソースサーバがクライアントを混同するような可能性のある属性を許可してはいけない
• クライアントとリソースサーバの間はTLSで保護されるべきである
• 認可応答はlocalhostおよびリダイレクトを使うネイティブアプリ（カスタムURIスキーム）を除き暗号化されていないネットワークを許可してはならない
• postMessageで認可応答を送信する場合は送信開始者と受信者の厳密な検証を行うこと
• 認可エンドポイントはユーザーエージェントが直接アクセスするためCORSを許可してはいけない

結構たくさんありますが、原則的なことが多いので実装する際のチェックとして利用すると良いと思います。

次回は続きを紹介したいと思います。