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 が
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
OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp
訂正 リダイレクト時の fragment の扱いを勘違いしていたため、本記事全体訂正します。 細かく訂正いれてると分けわかんなくなってきたんで、新しい記事書きました。 ゴールデンウィークまっただなかに Twitter で海外の ID 厨から袋だたきにあってたので、もうこの問題は片付いただろうとすっかり油断してた「Covert Redirect」の件ですが、日本でもゴールデンウィーク明けてバズりだしたので、一旦問題を整理した方がよさそうですね。 事の発端 Wang Jing さんていうシンガポールの大学院生が、こんなサイトを公開すると共に CNet はじめ各種メディアが取り上げたのが、バズりだした発端のようです。 前提知識 OAuth 2.0 や OpenID Connect だけでなく、OAuth 1.0 や OpenID 1.0/2.0 や SAML なんかでも、2つのサービスの間でリダ
Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと - OAuth.jp
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://oauth.jp/post/43684106049/re-oauth-20clientsecret/
OAuth.jpを立ち上げました。 - OAuth.jp