👹

ログイン中のアカウントと紐付けたOAuthのCSRF対策について

2020/12/12に公開

ritouです。これは何のアドカレの何日めでもありません。

普段から、OAuth 2.0やOIDCあたりのCSRF対策漏れってのを見かけた場合、報告したりしています。
いわゆるstateパラメータを使っていなかったり、雰囲気で認可リクエストに使っていると見せかけて検証していないケース*も見受けられます。

今回はそれらよりも一歩進んだ話で、どことは言いませんがこんな事案がありました。

こういう実装ってどうなのかについて自分の考えをまとめておきます。

ユーザーと紐づけられたstateにより何を守れるか

OAuth2.0におけるCSRF攻撃とは 「攻撃者が自らのセッションに紐づいた認可レスポンスを第3者に処理させる」 ものです。
対策として、認可リクエストのstateパラメータにセッションと紐づく値を指定し、認可レスポンスに含まれる値を検証することが仕様にも書かれています。

今回のように必ずログイン状態で行われる機能であるという前提を追加すると、攻撃者のユーザーIDに紐づいたセッションに紐づいた認可レスポンスを第3者が処理できてはいけないということになります。

そのために、今回のような ユーザーIDに紐づけられたstate を利用することにより、別のユーザーに紐づいた認可レスポンスを受け入れないという対策が行われていると言えるでしょう。実質これで問題はなさそう。

今回のstateの値には認可リクエストを生成した時刻と思われる値が入っていたので、それを検証することでstateの値が有効なものとして扱われる時間を制限できます。

上述の通り同一ユーザーのみ、さらにこの時間だけ使えるstateの値を使うことでCSRF対策をしているという主張もわからんでもありませんし、実際は確かに有用でしょう。

時刻の話やワンタイムとかをCSRF対策に入れるとちょいとややこしくなるので、一旦これはこれで良いとおいときます。

大抵のWeb Application Frameworkでは "未ログイン状態" でも "セッション" が発行され、例えばログインフォームのCSRF対策などで利用されます。

例えば、同じユーザーでログイン状態となっている複数のWebブラウザではログイン中のユーザーIDの値は同じですがセッションID" の値は別になるでしょう。また、ログアウトの際にセッションを更新してセッションIDを再発行する実装というのも割と一般的かと思います。

セッションに紐づけられたstateの値を使うことで、ユーザーに紐づけられたstateよりも利用できる範囲をより狭く留めておけますし、未ログイン状態でのOAuth/OIDC利用時にも利用できます。

例えば

ということをやると、ユーザーと紐づけられたstate であれば ユーザーIDが一致するので認可レスポンスは処理され、セッションと紐づけられたstate ではエラーと判定されます。

ログイン状態必須な機能かどうかによって設計を変えても想定している攻撃への対策ができていれば良いわけですが、このあたりは脳死で とりあえずセッションに紐づけておく と覚えておくで良いのではと個人的には思います。