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つのサービスの間でリダ
Googleがログイン認証を強化、OAuth 2.0の採用促す
米Googleは4月23日、2014年下半期以降にユーザーがWebブラウザやデバイス、アプリケーションからGoogleにログインする際のセキュリティチェックを段階的に強化すると発表した。 Googleではユーザーレベルで2段階認証などのセキュリティ強化策を提供するとともに、開発者向けには「Google Sign-In」などのツールを提供し、Google APIで認証プロトコルの「OAuth 2.0」をサポートしている。 今回のセキュリティチェックの強化は、本来のユーザーしかアカウントにログインできないことを確実にするのが目的。ユーザー名とパスワードをGoogleに送信しているアプリケーションでは、認証にOAuth 2.0を採用するよう開発者に促した。 Googleは、「OAuth 2.0を使わなければ、ユーザーがそのアプリケーションにアクセスするために、追加の手順を要求されるようになる」と
なぜOpenID Connectが必要となったのか、その歴史的背景
Prepared for #DevLOVE http://devlove.doorkeeper.jp/events/7419 Read less
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Covert Redirect and its real impact on OAuth and OpenID Connect
