Sign in with Apple の特徴分析 (1) - OAuth.jp
前記事 で書いたように、ここ数日 Sign in with Apple 用の RubyGem 作りながら、Sign in with Apple の特徴というか、他の IdP との違いみたいなところいろいろ調査したので、現時点での Sign in with Apple に対する雑感をまとめておきます。 Client ID と Team ID および App ID との関係 個人として Apple Developer Account 使ったことしかないんで、会社として Developer 登録してる時の Team の扱いとかよくわかってないんですが、Apple Developer Account 登録すると Team ID ってのが割り振られます。個人だと 1 Developer Account に 1 Team ID。 この1つの Team ID の下に、複数の子 App ID が登録可能で
LINE ID Login - OAuth.jp
LINE が OpenID Connect サポートしたみたいですね。 なんか前からしてんだと思ってたんですが、まぁいいや。 ということで、早速触ってみました。 こちらに今回使った Ruby のサンプルスクリプト置いておきます。 まぁ、ちょっと特殊な点がいくつかありますが、十分 OpenID Connect です。 気になった点は以下の通り。 ID Token の署名アルゴリズムが HS256 (HMAC-SHA256) HMAC ってことは、署名検証するために client_secret が必要ということです。 Native App で検証しようとすると、Native App に client_secret を埋め込まなければならない訳ですが、それはありえないので、要するに Native App で ID Token の署名検証はできないということです。 まぁ別に Native App
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
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では署名付ける代
"なんちゃら iOS SDK" でありそうな被害例 - OAuth.jp
昨日の続き。「ソーシャルゲームなんて3000万人の特殊な人しかやってない」という意見もあるようなので、今日は iOS アプリ版。 登場人物 iOS SDK 出してるプラットフォーム iOS SDK と連携するプラットフォームの公式 iOS アプリ プラットフォーム上で "まっとうな" アプリを運営してる攻撃者 攻撃者が自作した攻撃用アプリ iOS SDK 使って開発された被害アプリ あいかわらず無邪気な被害ユーザ 前提 プラットフォームが提供する iOS SDK は、 プラットフォームが指定するカスタムスキーマ (ex. “xyz-connect://”) で始まる URI にアクセスすることで プラットフォーム公式 iOS アプリに access token 取得のフローを delegate し 公式アプリが被害アプリの指定するカスタムスキーマ (ex. “foobar-rowial:/
「OAuth 2.0 (Implicit Flow) でログイン」の被害例 - OAuth.jp
。登場人物 OAuth 2.0対応してる某ゲームプラットフォーム 某ゲームプラットフォーム上で占いゲームを運営してる攻撃者 某ゲームプラットフォーム上で農園ゲームを運営してる被害アプリの開発者 某ゲームプラットフォーム上で無邪気に遊んでる被害ユーザ ※ 念のため、今回の話は特にゲームに限った話ではない。 前提 某ゲームプラットフォーム、農園ゲーム共に、XSS とか CSRF とかセッションハイジャックされるような脆弱性はない。 農園ゲームはプラットフォームが発行するAccess TokenをOAuth 2.0のImplicit Flowを使って受け取り、同じくプラットフォームが提供するProfile API (GET /me とか) にアクセスして、レスポンスに含まれる user_id をもとにユーザを認証している。 攻撃者は占いゲームのDBから任意のAccess Tokenを取得可能。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
