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 /
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
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 用
WebSocketでOAuth 2.0を使ってみた - OAuth.jp
WebSocket Serverでユーザー認証とか、WebSocket Serverの裏にRailsなりのAPIがあってNode.jsからそのAPI叩く見たいなのはそれなりにありそうなのに、あんまサンプルコード的なものが見当たらなかったので、自分で書いてみたのをここに公開することにします。 ClientがWebSocket Serverにつなぐ時、http://socket.example.com/?access_token=*** みたいなURLにアクセスして、ServerはそのToken元にユーザーを認証して、その後socketがつながってる間はNode.jsがそのtoken使って裏のRails APIにアクセスする、という使い方をしてます。 Access Tokenの保存先にMySQL使ってるのはあくまでRails側でそっちのが手っ取り早かったからで、ここはRedisでもMongoD
OAuth 2.0 Implicit Flow で認証の問題点、再び。 - OAuth.jp
おひさしぶりです、@novです。 最近は、新しいFacebook iOS SDK使ってるアプリを見つけるとまずToken置換攻撃を試みていますが、結構高い確率でこの攻撃に対して脆弱なアプリがみつかります。困ったものです。。 そんななか、2週間ほど前に、Micosoft Researchの人がIETF OAuth WGのメーリングリストに同じ問題を提起していました。該当Threadでは少し話題が脱線している部分もありますが、もともと最初にこの問題を提起したJohn BradleyがOAuth 2.0 CoreにSecurity Considerationsを追加する流れのようです。 これが現状の改善につながれば良いのですが、そう簡単に行かないかもなとも思います。というのも、この問題、なかなかデベロッパーにとって理解されない傾向があります。 そこで今日は、これまでいくつかのアプリデベロッパーに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://oauth.jp/post/51720772282/login-with-amazon/
