GitHub Business Plan 登場、GitHub.com ドメインで SCIM と SAML をサポート。 - OAuth.jp
オンプレサーバーで GitHub Enterprise をお使いのみなさま。 日々オンプレサーバーのメンテ、おつかれさまです。 GitHub.com の Business Plan っての、良さそうですよね。 SCIM と SAML サポートしてて、いままでオンプレ版でしかできなかった Provisioning と Federation (SSO といった方が伝わるか？) が、GitHub.com ドメインでできるようになったんですよ。 これで GitHub.com が生きてればいつでも Deploy できますよ。 死ぬもんね、オンプレ。てか、一旦死んだら結構しばらくの間死ぬもんね、オンプレ。 GitHub.com なら、AWS が生き返ればきっと生き返るよ。 ということで、Business Plan の SAML と SCIM、ちょっと試してみましたよ。 SAML 設定 GitHub H
HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
OAuth / Connect における CSRF Attack の新パターン - OAuth.jp
昨日こんなのが OAuth ML に流れてました。 [OAUTH-WG] Another CSRF attack 前提条件 RP (Relying Party a.k.a. OAuth Client) が2つ以上の IdP (Identity Provider a.k.a. OAuth Server) と連携している状況で、片方の IdP に悪意がある。 悪意ある IdP = AIdP (A は Attacker の略) その他の IdP = HIdP (H は Honest の略) 攻撃フロー Victim が AIdP を使って RP へのログインを試みる。 RP は Authorization Request を AIdP に送る。 AuthZ Req には Browser Session と紐付いた state パラメータをつけている。 AIdP は Victim を認証し、必要に
FB Message API Callback as an Azure Function - OAuth.jp
今日は Azure Function で FB Message API Callback を作ってみます。 Azure Function は、Azure Portal の Marketplace で “Function App” って検索すると出てきますね。 Function App の Deploy がおわったら、QuickStart から “Webhook + API” を選びましょう。 以下の様な Node.js のテンプレートアプリが出来上がります。 まずは FB Message の WebHook としてこの Function を登録します。 Azure Function の Function URL を FB Message API の WebHook Callback URL に登録して、適当な verify_token を設定します。 WebHook Verificatio
「OAuth 認証」を定義しよう - OAuth.jp
「OAuth 認証」って言葉が出てくると、「認証と認可は違う」とか言い出す人が出てきて、大体の場合「OAuth 認証」言ってた人たちがやりたいことの話とはズレた議論が始まるので、もういっその事「OAuth 認証」とは何かを定義してみましょうかね。 「OAuth 認証」で Relying Party (RP) がやりたかったこと RP (OAuth Client) は、ブラウザの前にいる人を、認証したかったんですよね？ もう少し正確にいうと、ブラウザの前にいる Entity が、RP 側で把握しているどの Identity と紐付いているか、というのを知りたかったんですよね？ いきなり Entity とか Identity とかいう専門用語が出てきてアレですが、そのあたりのことは先日の OpenID TechNight #13 でもお話ししたので、以下のスライドの Entity・Identi
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
個人情報保護法改正案に見る第三者提供記録義務と越境問題 - OAuth.jp
先日の「属性単位のトレーサビリティについて」という記事でも取り上げましたが、個人情報保護法改正案では、第二十五条に「第三者提供に係る記録の作成等」という規定が設けられ、第三者提供時に提供者受療者双方に記録義務が発生することとなっています。 また土曜日に行われた情報法制研究会第1回シンポジウムこの提供記録義務と、同じく改正案第二十四条の「外国にある第三者への提供の制限」を組み合わせると、AWSにデータ保存 (委託行為？) するだけで、第三者提供扱いとなり、記録義務が発生してしまうのではという指摘がありました。(まとめからのリンク先、板倉先生の資料参照。パスワードは空気読んで頑張って探してください。) 20150328情報法制研究会 第1回シンポジウム「改正個人情報保護法の内容と今後の課題」関連まとめ(私家版) 確かに第二十四条では、認定国もしくは認定事業者以外の外国事業者に対するデータ提供の
JWS 実装時に作りがちな脆弱性パターン - OAuth.jp
JOSE (Javascript Object Signing and Encryption) 愛で満ち溢れる ID 厨界隈において、燦々と輝く JWS (JSON Web Signature)、美しいですよね！ JWT がジャニーズなら、JWE は EXILE、JWS は石原さとみと言ったところでしょうか？ と、冗談はさておき、JWT をお使いの皆さんは、当然署名付けてますよね？署名検証しますよね？ そんなあなたに一言いいたい！ まだ HMAC で消耗してるの？ いや、決して HMAC オワコンとかは言ってないですよ？スマホアプリでの署名検証のために、アプリに共通鍵埋め込むのはナンセンスってだけで。 ということで、今日は JWS をお使いのみなさんに、実装時に作りがちな脆弱性パターンを2つご紹介します。 今日紹介する脆弱性の2つのうち、1つめは HMAC, RSA, ECDSA のどれを
Google OpenID 2.0 のサポート終了、OpenID Connect への移行はお早めに - OAuth.jp
今朝こちらの Tweet みて気がついたんですが、Google が OpenID 2.0 のサポートを2015年4月20日で終了するようです。 Developers beware! Google has published its timeline for deprecation of OpenID 2.0:http://t.co/84cIS0wR1D — Gluu (@GluuFederation) January 7, 2015 本当にそんな短期間で OpenID 2.0 止めて大丈夫なのかって気がしますが、Google OpenID 2.0 Shutdown Timetable によると、4/20で全てが止まるようです。 僕が把握しているところでは、以下のサイトは現時点でまだ Google OpenID 2.0 を使っています。他にもいっぱいあるんでしょうが、僕は把握してません。他に
Twitter Login にも CSRF 脆弱性ができやすい罠が!? - OAuth.jp
OAuth 2.0 では state パラメータってのがあって、それをちゃんと使わないと CSRF 脆弱性ができちゃうよって話は、@ritou 先生のスライドなどでみなさん勉強したんではないでしょうか。state パラメータは RFC 6749 では RECOMMENDED 扱いで、REQUIRED ではありませんが、OAuth 2.0 をログインに使う場合は REQUIRED にすべきでしょう。OAuth 2.0 をログインに使うの、Token 置換攻撃とか Covert Redirect + Code 置換攻撃とか、いろんな罠がありますねぇ〜。 OAuth 1.0 ならそんなことないのに… そう思ってた時期が、僕にもありました。 でも @ritou 先生よく言ってるじゃないですか。「Twitter の OAuth 実装クソや」って。でね、ほんとにクソやったんすよ、コレが。 さて、Dev
OAuth 2.0 の code は漏れても大丈夫ってホント!? - OAuth.jp
昨日のCovert Redirect で Query 漏れるケースもある!?やOAuth 2.0 の脆弱性 (!?) “Covert Redirect” とはにあるように、OAuth 2.0 の code が漏れちゃうことも、ありえます。 漏れないためにやるべきことは、上記の記事やFacebook Login で Covert Redirect を防止するなんかでも紹介してるので、そちら読んでください。 で、今回の内容は「code が漏れたら何がまずいのか」についてです。 「code は漏れても大丈夫」説 「Covert Redirect」についての John Bradley 氏の解説（追記あり）にも、こうありましたね。 OAuth と OpenID Connect には複数の response_type があるんだけど、さきのリポートの著者は、最も一般的な response_type が
Covert Redirect で Query 漏れるケースもある!? - OAuth.jp
Covert Redirect 連載最後は、location.href とか <meta http-equiv=“Refresh”> とかだと referrer 通じて query に含まれる code とかも漏れるかもね！ってお話です。 古いサイトですが、こことか見れば大体いいんじゃないでしょうか => リファラ実験 で、こういうリダイレクトをしてる箇所が OAuth 2.0 の redirect_uri なり OpenID 2.0 の return_to なりに指定されていれば、query に付いた code なり email なりがリファラ経由で外部に漏れるよね、という。 はい、漏れますね！ (投げやり さて、そんなに該当例多くはないと思うのですが、ここまで該当してしまったサービスは、どうしますかねぇ… Facebook であれば、Facebook Login で Covert Re
Facebook Login で Covert Redirect を防止する - OAuth.jp
OAuth 2.0 Implicit Flow では Covert Redirect 経由で access token が漏れる件については既に紹介しましたが、ここではみなさん大好き Facebook Login で OAuth Client Developer ができる対策について紹介することにします。 攻撃方法 攻撃対象となる OAuth Client の FB client_id を取得 client_id は FB Login ボタンさえクリックすればアドレスバーに表示される。 Authorization Request URL を構築 対象 Client が通常 response_type=code を使ってる場合でも、問答無用で response_type=token にしてください。 https://www.facebook.com/dialog/oauth?client_i
OpenID 2.0 における Covert Redirect と RP Discovery - OAuth.jp
さて、OAuth 2.0 & OpenID Connect における Covert Redirect の問題 についてはまとめたので、次は OpenID 2.0 についてです。 いいですか、OpenID Connect ではなく、OpenID 2.0 ですよ。古い方です。懐かしいですね、OpenID Authentication 2.0 – Final。 そういえば、OpenID Foundation Japan の翻訳 WG を立ち上げて、一番最初に翻訳したのが OpenID Authentication 2.0 の 日本語訳でしたね…(遠い目 と、昔話はそれくらいにして、本題に入りましょう。 まずは Covert Redirect 発生条件について OpenID 2.0 では、レスポンスパラメータは query に引っ付いてきます。fragment は使いません。 なので、open r
Implicit Flow では Covert Redirect で Token 漏れるね - OAuth.jp
この記事は、先ほど書いたこちらの記事の訂正版です。 記事に入る前に、まずは全シンガポールにお詫び申し上げますm m さて、Covert Redirect についての説明は…超絶取り消し線はいりまくってる前の記事を読んでください、でいいでしょうか？ で、訂正分だけ以下に。 Fragment Handling in Redirect 宮川さんが記事にしてますね。 英語だけど。 で、まぁ要するに、(Modern Browser は) 30x リダイレクト時にリダイレクト元に付いてた URL fragment をリダイレクト先にも引っ付ける、と。 fragment は server-side には送られないけど、クライアントサイドではリダイレクト先に引き継がれる、と。 試しに http://www.idcon.org/#foobar にアクセスすると、http://idcon.org/#fooba
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Office 365 SAML implementation vulnerability - OAuth.jp