情報処理安全確保支援士(情報セキュリティスペシャリスト) 試験情報＆徹底解説

https://www.sc-siken.com/kakomon/04_haru/
令和4年春期試験問題 午後Ⅱ問2設問4(3)
O-Auth2.0のCSRF対策について

最近やっとO-Auth2.0の通常のフローが理解できてきたのですが、壁にぶつかってしまいました。

問題のstateの値を比べて一致してなければ、攻撃を検知することができるという答えはわかるのですが、攻撃者が何がしたいのか、全く理解できずにいます。

O-Auth2.0のCSRFは攻撃者のリソースを被害者に使わせるということですが、それはなんのために使わせるのでしょうか。自分のリソースを使わせるなんて優しいやつだなとかおもってしまいます。

会議登録の不正じゃ、いまいちピンとこないので、できればもう少し犯罪っぽい例のシナリオで教えていただければと思います。

この投稿は投稿者により削除されました。(2024.02.07 23:06)

たしかにOAuthのCSRFは分かりにくいです。
通常のCSRFは攻撃対象者の認証・認可状態を攻撃者が横取りするといものです。
しかし、OAuthのCSRFはこれとは逆で、攻撃者の認証・認可状態を攻撃対象者に
渡すというものです。
これにより何が起きるかというと、考えられるケースとして不正な情報の
流出があります。

攻撃対象者はCSRFによって知らぬ間に攻撃者の認証・認可状態を渡されます。
攻撃対象者は機密データを自分のクラウドストレージにアップロードしたつもりが、
攻撃者のストレージにアップロードしていたというようなことも起こります。
このようにプライベートな情報が知らぬ前に流出していたということが
CSRFによって引き起こされます。

図解：OAuth 2.0に潜む「5つの脆弱性」と解決法
【攻撃手法1】Cross-Site Request Forgery（CSRF）
デジタルID最新動向（2）
2017年10月24日 05時00分 公開
[ritou（OpenID Foundation Japan），＠IT]
がわかりやすいです。

pixさん
GinSanaさん
回答ありがとうございます。

まだちょっと理解できずにいて、もう少し追加で質問させてください。
どのような不正が起こってしまうということは理解できました。
ですが、これはクライアントアプリ（被害者アカウント）とリソースサーバ（攻撃者アカウント）の連携がされているという構図ですよね。

攻撃者はクライアントアプリ（攻撃者のアカウント）にて認可サーバに攻撃者自身のアカウント情報で認可要求するので、認証したあと発行された認可コードを被害者に送ったあと被害者がその認可コードを使ってアクセストークンを要求しても、認可コード（攻撃者のアカウントに紐づいている）に対してアクセストークンは紐づけられ、どっちみちアクセストークンはリソースサーバ（攻撃者のアカウント）として発行され、
結果として、クライアントアプリも攻撃者のアカウント、リソースサーバも攻撃者のアカウント情報を使うことになり、攻撃者が不正を行えることは無いとおもってしまうのです。

攻撃者の自身のアカウント情報で作成した認可コードをつかっているのに、クライアントアプリ（被害者のアカウント）とリソースサーバ（攻撃者のアカウント）の連携ができるのですか？

わかりにくい質問で本当にすみません。

OAuthのフローに関して誤った認識を持っているように見受けられます。

前提として、被害者、攻撃者ユーザはクライアントアプリ側（Sサービス）と、認可サーバ、リソースサーバ側（Gサービス）にアカウントをそれぞれ持っています。
そしてSサービスとGサービス間ではお互いのアカウント情報は見えていませんし、アカウント情報の連携はされていません。

以下がフローになります。
1.Sサービスで連携ボタン等を押すと、Gサービスへ認可の要求をブラウザを経由して行います。  図9.(1)~(3)
（リダイレクトを使用、この際SサービスはGサービスに対してSサービスのログイン中のユーザ情報は送りません）

2.Gサービスはブラウザへ認可画面を表示する。図9.(4)
（Gサービスへのログインや、認可の確認画面等）

3.ユーザがGサービスへログインし承認ボタンを押すなどを行うと、Gサービスがブラウザを介してSサービスへ認可コードを送信する。 図9.(5)(6)
（リダイレクトを利用、このリダイレクトを攻撃者が止めて利用するのがCSRF）

4.Sサービスは認可コードが送られてきたら、Gサービスへ認可コードを直接送信する。図9.(7)
（この際にSサービスからみると、認可コードはGサービス上のどのアカウントのものかわからない）

5.Gサービスは認可コードを受け取ると、認可コードを発行したユーザのスケージュール情報を取得できるアクセストークンを発行し、Sサービスへ送信する。（この際、Gサービスからみて、認可コードを送ってきたSサービスへログイン中のユーザは誰かわからない）図9.(8)

6.Sサービスがアクセストークンを使用して、Gサービスからスケージュール情報を取得する。図9.(9)(10)

問題は、認可コードを要求したユーザと、使用したユーザを確認せず、認可コードが正しい値かであればアクセストークンが発行されてしまう点です。

これを解決するためにSサービス上でSサービスのセッション情報+stateの組を管理しておくことで、認可コードが誰のものかをSサービス上で管理します。発行時と別の人が認可コードを使用しようとした場合、セッション情報+stateの組が登録されていたものとことなるためエラーになり、SサービスがGサービスへの認可コードの送信を行なわないため、Gサービスからアクセストークンが発行されることはありません。

質問内容を勘違いしていたら申し訳ありません。また文章で表現することが難しく、わかりずらかったら申し訳ありません。

むぐむぐさん
回答ありがとうございます。

＞OAuthのフローに関して誤った認識を持っているように見受けられます。
全くその通りだと思います。アカウント連携についても少し誤解していたようです。

まだ完全には理解できておりませんが、
認可コード発行の際の挙動やアクセストークンの中身についても、改めてもうすこし詳しく調べてみます。もう少しかかりそうですが。。
ありがとうございました。