OAuth.jp

OAuth IdP Mix-Up Attack とは？ のつづき。

OAuth ML上で、以下のどちらを採用すべきかについての議論が収まる気配のない昨今です。

• http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation
• http://tools.ietf.org/html/draft-sakimura-oauth-meta

そんななか、もうちょっとややこしいというか致命的なケースが出て来ました。

• Code phishing attack on OAuth 2.0 [RFC6749] | .Nat Zone

“Mix-up Attack” っていうやつの話をしてたはずが、いつのまにか “Code Phishing Attack” って名前になっててもはや2つの違いがよく分かんなくなってきますが、ブログ記事中では「フィッシングメールをRP Developerに送って、Client DeveloperにToken Endpointを書き変えさせる」というパターンが例示されています。

いや、そんなんに騙されるやつおらへんやろ〜、ってのがだいたいの反応かとは思いますし、RP Developerのみなさんがちゃんと注意しれてばそれで十分な話ではあるかと思います。

が、IdP視点でいうと、アホなRPからユーザーさんのTokenとかそのRPのclient_secretとかがだだ漏れになっちゃうとIdPのレピュテーションにひびいたりするので、なかなかつらいところです。

もはやここまで騙されてる状況では、Authorization Response以外何も信用できない訳で、Authorization Endpointにiss含んでも、issに紐付いたIdP Configがstaticにhard-codeされてるなら、そのhard-codeされてるconfig自体信用できないということになります。

「IdPごとに別のredirect_uriを使う」なんてのも、もはや無意味ですね。

response_type=code+id_tokenとして、fragmentについてきたID Tokenをチェックしても、Discovery無しだとダメでしょう。

そのため、IdPが取れる対応策は以下の2つのどちらかになるでしょう。

• issを返しつつ、OAuth Discoveryをサポートする
• OAuth MetaのようにToken Endpoint URLをAuthZ Responseに含める

前者は http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation をより厳しくしたもので、後者は http://tools.ietf.org/html/draft-sakimura-oauth-meta そのものです。

個人的にはOAuth Discoveryが必須になるとHTTP Requestが増えるので、IdP的にはあまり嬉しくないなぁと思います。

ps.

Implicit FlowにおいてResource Endpointが書き換えられていることを想定したケースでは、AuthZ ResponseにResource Endpoint(s) を含めることになって、Code Flowよりさらにややこしい話になるわけですが、それはまた別の機会に…書く…かも。

成人式を迎えられたID厨の皆様におかれましては、大変おめでとうございます。成人前からID厨とか、キモカワですね。

さて、今日は、成人式直前にOAuth MLに投下された以下のpostで「OAuth 2.0の脆弱性」として紹介されている “IdP Mix-Up Attack” について紹介します。

[OAUTH-WG] OAuth Security Advisory: Authorization Server Mix-Up

前提条件

• End-UserとRPの間の (TLS-protectedでない) HTTP Request/ResponseをAttackerがproxy可能。
• RPが2つ以上のOAuth Server (IdP) と接続しており、そのいずれかが攻撃者の管理下にある。(IdPの中の人が実は攻撃者だった etc.)
• RPは複数のIdPに対して共通のredirect_uriを利用しており、そこへのcallbackを受け取った時にstate値を元にIdPを特定する。
  • ただしIdP側のredirect_uri検証が「事前登録済の値との完全一致」でない場合は、この通りではない。

攻撃フロー

以下、Attackerの管理下にあるIdPをAIdP (Attacker IdP)、その他の悪意ないIdPをHIdP (Honest IdP) と呼ぶことにします。

1. End-UserはRPの任意のページから「HIdPでログイン」ボタンをクリック。
2. Browser->RPへの (TLS-protectedでない) リクエストをProxyしたAttackerは、RPに「AIdPでログイン」するリクエストを送信し、AIdPのAuthorization EndpointへのRedirect Responseを受け取る。
3. AttackerはBrowserにHIdPのAuthorization EndpointへのRedirect Responseを返す。ただしstate値は2で受け取った「AIdP向けのAuthorization Requestとひもづいた」値を利用する。(これ以降全リクエストはTLS-protectedであるためAttackerのProxyは介入不可)
4. End-UserはHIdPでApproveボタンをクリック。
5. HIdPはstateとcode/tokenをquery/fragmentにつけた状態で、End-UserをRPのredirect_uriに戻す。
6. code/tokenを受け取ったRPは、state値を元に受け取ったAuthorization ResponseがAIdPからのものだと判断する。
7. RPはAIdPのToken EndpointやAPI Endpointにcodeやtokenを送りつけてしまい、HIdPのcodeやtokenがAIdP (攻撃者) の手に渡る。

Read on →

Identity 界隈の皆様は、11/10 に OpenID Summit 2015 が開催されることはすでにご存知かと思いますが、OAuth / JWT 愛なみなさまの中にはまだご存知ない方もおられるかもしれないので、こちらでも告知しておきますね。

はい、やります！

タイムスケジュール みていただいてもおわかりのように、IETF 横浜の翌週というタイミングで、かつ OpenID Foundation (Global の方) の全面協力もあり、OpenID Foundation から主要な外タレ勢揃いな感じでございます。JWT Love なみなさんは、もちろん Mike Jones への愛を忘れたことはないでしょうし、強面やのになぜかプーさんキャラな John Bradley は IETF OAuth WG の各種最新 RFC および draft の解説をしてくれます。

もちろんメインホールでは日本語のセッションもやっとります。日本語セッションは、Identity 技術活用事例とか FINTECH とかマイナンバーとか IDaaS とか…

あと、毎度おなじみエバ企画、今回は OpenID Connect Certification の体験 Hands-on です。

• OpenID Connect IdP を実装したけど、本当に自分の実装が OpenID Connect 仕様に準拠してるのか確認したい方
• OpenID Connect ライブラリを実装したけど、Connect 準拠の IdP を作るのに事足りるライブラリになってるか確認したい方
• なんちゃって Connect 実装とか、なんちゃって OAuth 認証実装したけど、あとどれくらいで Connect 準拠になるのか知りたい方

そんな方々に、IdP 実装の Connect 準拠具合をテストするためのツールがあります。

OpenID Connect Certification Hands-on では、テストツールの使い方を紹介後、実際みなさんの実装に対してテストを実行していただき、テストが失敗したものに関する Debug のお手伝い等もさせていただきます。

Global の方の OpenID Foundation からも、Mike Jones が Hands-on 会場に来てくれるようなので、Mike の OpenID Connect Certification のセッションをみた後、そのまま Hands-on に参加すると良いと思います！

ということで、申し込みはこちら！

一気に出ましたね。すでに過去にもいくつかは紹介したり翻訳したりしていますが、それぞれを簡単に紹介しておきます。

JOSE WG

• RFC 7515 – JSON Web Signature (JWS)
• RFC 7516 – JSON Web Encryption (JWE)
• RFC 7517 – JSON Web Key (JWK)
• RFC 7518 – JSON Web Algorithms (JWA)
• RFC 7520 – Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)

JWS は署名付きのデータを JSON (の Base64 URL Encode) 形式で表現するための仕様で、多くの場合は JSON Payload に対して署名するケースで利用されます。JSON じゃないデータに対して署名して、署名結果を JSON (の Base64 URL Encode) 形式で表現することもできますが…まぁ、細かい話は置いときましょう。OpenID Connect の ID Token とかは、JWS 仕様に従って署名されています。

JWE は暗号化されたデータを JSON (の Base64 URL Encode) 形式で表現するための仕様です。現状では JWS よりは利用頻度低いかとは思いますが、SAML Assertion を暗号化してるようなユースケースを Connect に移行する時なんかには使うでしょう。

JWK は JWS や JWE などで利用する鍵を JSON 形式で表現するための仕様です。上記2つとよくセットで利用されます。OpenID Connect でも、OpenID Connect Discovery をサポートしているような IdP では大体公開鍵を JWK Set 形式で公開していますね。

JWA は、JWS や JWE で利用される各アルゴリズムおよびそれらの識別子を定義している仕様です。JWT, JWS, JWE をライブラリを通じて利用しているケースでは、あまり気にすることはないでしょうが、JOSE ライブラリ作者は読むことになるでしょう。

最後のは、サンプルリストですね。これはまぁライブラリ作者が読むくらいでしょう。

OAuth WG

• RFC 7519 – JSON Web Token (JWT)
• RFC 7521 – Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7522 – Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7523 – JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

JWT は JSON (の Base64 URL Encode) 形式で Assertion を生成するための仕様です。OpenID Connect の ID Token などで利用されています。大抵は署名 (= JWS) とセットで利用されるでしょう。

Assertion Framework for OAuth 2.0 (ry) は、任意の Assertion を OAuth 2.0 の Client Authentication で Client Credentials として使ったり、Authorization Grant として利用して Assertion を Access Token と交換するための仕様です。これ単体では利用できず、後の2つのサブ仕様の共通部分を抽象化した仕様になっています。

SAML 2.0 Profile for OAuth 2.0 (ry) は、SAML Assertion を RFC 7521 の Assertion として利用するための仕様です。既存の SAML SP が持っている SAML Assertion を OAuth 2.0 の Access Token と交換して API Access させたいとか、そういう時に使います。「あぁ、それは SAML 単体じゃ無理なんで、ID-WSF 必要ですねぇ〜」って言われたら、多分 ID-WSF 無視してこれ使えば、OAuth 2.0 使えるようになるはずです。

JWT Profile for OAuth 2.0 (ry) は、JWT を RFC 7521 の Assertion として利用するための仕様です。Client Authentication 目的で利用するケースは、ADFS / Azure AD とかであるはずですが、Authorization Grant として利用するケースは…あったかな？

Links

• JSON Web Token (JWT) – OAuth.jp
  • もうこの記事書いてから、2年半経ってるんですね〜。感慨深い。
• JWS 実装時に作りがちな脆弱性パターン – OAuth.jp
  • すでに JOSE ライブラリは大体出揃ってるので、今後新しく作ることはあまりないかもしれませんが、もし自分で JWS 実装する時は、これ注意してくださいね。
• 翻訳ドキュメント一覧 – OpenID Foundation Japan 翻訳 WG
  • Draft 版の JOSE 仕様群は、こちらに翻訳版あります。
• JWSとJWTがRFCになりました！ – @_Nat Zone
  • Nat さんはじめ、みなさんおつかれさまでした！

先日の「属性単位のトレーサビリティについて」という記事でも取り上げましたが、個人情報保護法改正案では、第二十五条に「第三者提供に係る記録の作成等」という規定が設けられ、第三者提供時に提供者受療者双方に記録義務が発生することとなっています。

また土曜日に行われた情報法制研究会第1回シンポジウムこの提供記録義務と、同じく改正案第二十四条の「外国にある第三者への提供の制限」を組み合わせると、AWSにデータ保存 (委託行為？) するだけで、第三者提供扱いとなり、記録義務が発生してしまうのではという指摘がありました。(まとめからのリンク先、板倉先生の資料参照。パスワードは空気読んで頑張って探してください。)

20150328情報法制研究会 第1回シンポジウム「改正個人情報保護法の内容と今後の課題」関連まとめ(私家版)

確かに第二十四条では、認定国もしくは認定事業者以外の外国事業者に対するデータ提供の場合は、下記のように第二十三条の例外規定 (委託や共同利用を第三者提供として扱わないという規定含む) を適用しないと明記しているので、委託の場合でも第三者提供扱いとなり、記録義務が発生することになりそうです。

この場合においては、同条の規定は、適用しない。

さらに外国事業者への提供時には、通常の同意とは別に外国事業者への提供であることを明記した上での同意を取得する必要があるため、海外のRPを相手にする国内IdPは、

• RPが国内事業者であるか否か
• RPが海外事業者である場合には認定国の事業者であるか否か
• RPが非認定国の事業者である場合には認定事業者であるか否か

を判断した上で、いずれにも当てはまらない場合は通常とは別の同意文言を提示する必要が出てきそうです。

いやぁ〜、Dynamic Registrationとかしてる場合じゃないっすね！

どうしましょか、これ？w (ノーアイデァなぅ)