引き続きOAuth2.0 Security Best Current Practiceを読んでいきます。
今回も攻撃パターンと緩和策についてみていきます。前回18パターンのうち始めの3つを紹介したので、今回は続きを紹介していきます。
攻撃パターンと緩和策
このセクションでは攻撃ごとに緩和策が記載されています。ここまでのベストプラクティス、攻撃モデルを考慮して、自身の実装を分析し該当する攻撃パターンが当てはまる可能性があるなら緩和策を考える、という使い方になると思います。
- Mix-Up攻撃
- 一番有名な攻撃なんじゃないでしょうか。8年前にnovがoauth.jpに詳細をアップしているのでこちらを読むのが良いとおもいます
- とはいえ本題はBCPなのでこちらを読んでいくと、亜種に関する説明があります
- Mix-Up with Interception
- 前提として攻撃者がユーザ（被害者）の認可リクエストとレスポンスを傍受できる環境にあることが設定されています
- 通常のMix-Upでは攻撃者が用意した認可エンドポイントで正直な認可サーバへリダイレクトしますが、このケースでは正直な認可サーバへのリクエスト〜レスポンスを傍受し、攻撃者の認可サーバへ強制的にリダイレクトします。あとは通常と同じ流れですね
- インプリシットグラント
- インプリシットグラントの場合、認可コードではなくアクセストークンを直接受け取るわけですが、受け取ったアクセストークンを攻撃者が用意したuserInfoエンドポイントへ投げ込まさせることで攻撃者がアクセストークンを搾取する、というシナリオです
- 認可サーバごとのredirect_uri
- 複数認可サーバが存在するケースにおいてクライアントが選択した認可サーバをセッションに保存せず、redirect_uriの検証を正しく行わない場合、認可サーバとredirect_uriの組み合わせがおかしくなる、というシナリオです
- OpenID Connect
- Discoveryのメカニズムを悪用するケースですね。ログイン時にwebfingerでメールアドレスのドメインパートからwell-knownエンドポイントを探してきますが、この際にメールアドレスのドメインを置き換えることで攻撃者のIdPのエンドポイントへ誘導、動的クライアント登録の仕組みでRPを登録させてしまう、その後は通常のMix-Upと同じという感じでしょうか
- 緩和策
- そもそも論としてクライアントが単一の認可サーバのみと連携している状態ではMix-Up攻撃は出てきませんので、そのような場合は除外できます
- 基本的な考え方としては、認可リクエストをどの認可サーバに送信したのかをクライアントがきちんと覚えておくことが最も重要です
- 認可サーバの識別を行うにはissクレームを使い、きちんと評価する必要があります
- redirect_uriが複数の認可サーバで共用されてしまうことよる問題を避けるにはクライアントは認可サーバごとにredirect_uri（コールバック先）を分ける必要があります
- 認可コードのインジェクション
- これも有名な攻撃ですね。何らかの方法で搾取した認可コードを攻撃者のセッションの中に注入することで不正にアクセストークンの取得をするわけです
- 具体的には、こんな流れですね
- 攻撃者は何らかの方法で認可コードを手にいれる
- 攻撃者は正規のクライアントから認可コードフロー改めて開始する
- 認可エンドポイントから発行されてくる攻撃者の正しい認可コードを不正に入手した認可コードに置き換える
- この結果、攻撃者は不正に被害者のアクセストークンを取得できてしまう
- この攻撃は認可コードを使い捨てにすること、そもそも認可コードを盗まれないようにするためにredirect_uriのチェックをする、などの対策が可能です
- 緩和策
- PKCEやnonceを使うのが基本です
- アクセストークンインジェクション
- 不正に入手したアクセストークンを利用して別ユーザになりすましてリソースサーバへアクセスができてしまう、という問題です
- 緩和策
- 正直OAuthではアクセストークンがトランザクションやUserAgentにバインドされないため、アクセストークンを搾取されたらおしまいではあります
- OpenID Connectを使う場合はat_hashやnonceを使ってトランザクションの整合性を検証することも大切です
今回も3つばかり紹介しました。
では、またお会いしましょう。
投稿
0 件のコメント:
コメントを投稿