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タグは割と普通に実装されている気がするので十分に注意しましょう。