なるほど、↑の記事が詳しいが、ALBに関連づけられた IdP で認証をした後に、Idp を変更し、
トークンがリフレッシュされると変更先の IdP を issuer としてALBトークンを生成してしまうようである。
記事を読むまでは、JWTでよくある署名の検証をしていない場合にのみ攻撃を受けるのかなと思っていたがそうではないらしい。
issuer の項目は任意のものを挿入されてしまうようだが、 signer は偽造することができないようで、
signer にはALBトークンを生成した ALB の arn が入るようだ。
なので、想定された ALB のトークンであるかを検証するようにドキュメントが修正されたようだ。↓
(冒頭の記事より)
また、これは ALB をバイパスして直接アプリにリクエストが飛ばせてしまう場合に影響を受けるようだ。
AWS になれている人にとっては当たり前かもしれないが、アプリが public subnet に存在する場合、
Security Group で 特定のALB からのみリクエストを受け付ける設定をしていないと、ALBを経由せずにアプリへアクセスできてしまう。
ALBがバイパスできてしまうと、任意のトークンを渡されてしまい、なりすまされてしまう可能性があるよということだろう。
なので、記事にもあるが、
- JWT(x-amzn-oidc-data)の署名の検証に加えてsignerフィールドの検証を行う
- アプリはALBからのみ通信を受け付けるようにする
ということに気をつけていれば良さそう。
気をつけるべき構成は以下のような条件1,2を両方満たす構成である場合だ
てっきり、認証後に払い出される ALB のCookieが、他のALBでも使えてしまうとかそういう系のバグだと思っていたがそうではないようだ。思ったより深刻ではない気がする。
ALBに関連づけられた IdP で認証をした後に、Idp を変更し、トークンがリフレッシュされると変更先の IdP を issuer としてALBトークンを生成してしまう
ただ、この挙動は良くないよねとは思う。