RFC7636として発行されたOAuth PKCEとは - r-weblife
おひさしぶりです、ritouです。 今日は家で風邪治してましたが、TLに流れてきた次世代なんちゃらの話題に乗っかって、ざっくりとした仕様紹介です。 ベンダー個別のパスワード管理には課税せよ！？ 次世代Webカンファレンス『identity』 #nextwebconf #nextwebconf407 - Togetter OAuth PKCEがRFC7636として発行されました。 | @_Nat Zone RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients 一言でいうと この規格はOAuth 2.0 [RFC6749]のPublic Client の Code Interception Attack 脆弱性に対応するもので、ephemeral keyを生成して、これを使ったProof of Possession of
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
Covert Redirect is not new but.. A risk analysis and recommendations
Covert Redirect is not new but.. A risk analysis and recommendations So, there has been a flurry of worries induced by the CNET and other articles [1] about “Covert Redirect”. Like Leandro Boffi wrote in his blog post [2], this is not a new attack. It is an attack that has been known for at least 6 years. It is very disappointing that, after this long years, there still are sites this buggy, but w
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つのサービスの間でリダ
OAuthとOpenIDに深刻な脆弱性か--Facebookなど大手サイトに影響も
OpenSSLの脆弱性「Heartbleed」に続き、人気のオープンソースセキュリティソフトウェアでまた1つ大きな脆弱性が見つかった。今回、脆弱性が見つかったのはログインツールの「OAuth」と「OpenID」で、これらのツールは多数のウェブサイトと、Google、Facebook、Microsoft、LinkedInといったテクノロジ大手に使われている。 シンガポールにあるNanyang Technological University（南洋理工大学）で学ぶ博士課程の学生Wang Jing氏は、「Covert Redirect」という深刻な脆弱性によって、影響を受けるサイトのドメイン上でログイン用ポップアップ画面を偽装できることを発見した。Covert Redirectは、既知のエクスプロイトパラメータに基づいている。 たとえば、悪意あるフィッシングリンクをクリックすると、Faceboo
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を使わなければ、ユーザーがそのアプリケーションにアクセスするために、追加の手順を要求されるようになる」と
ユーザー認証の手抜き - 方向
Webアプリ作っているといろんな局面でユーザー認証が必要になる局面がある。まじめにつくると果てしなく面倒だし、適当につくるとセキュリティ上問題になるので、要件に応じて適切に手抜きする必要がある。 適当なやつからしっかりしたやつまでなんとなくソートしていくとこんなかんじだと思う。 認証なし IPで弾く Basic認証（ソースコード、設定ファイルにパスワードベタ書き） Basic認証（DBにUserテーブルをつくってパスワードを保存。追加はcliとかで手動） login/logout画面作成。cookieなりmemcacheなりにセッションを保存 webからユーザーを追加できるように password変更機能 OAuth OpenID mailを送ってリンクをクリックさせてメールアドレスの所有確認 メールアドレス変更機能 メールを使ってのパスワードリセット機能 OAuthで作ったアプリへの後か
Cookie使ったセッション管理も認可だと思うわって話 - r-weblife
こんばんは、ritouです。 OAuthが認可の仕組みだっていうのはだいぶ広まった感ありますね。 でも、なんかまだしっくりこないっていう人いると思います。 その理由の一つとして、Webアプリケーションでよく使われている”Cookieを使ってログインセッションを保持する”しくみ、あれが一般的に認証って言われてるせいじゃないかと思ったりします。 こいつ、OAuthと同じで、途中で認証もしてるけど、全体で見ると認可のしくみじゃねーか的な感じで書いて見ます。 いわゆる”Webアプリケーションの認証フロー”は次のような感じでしょう。 ブラウザはログイン画面を表示 ブラウザは入力されたメアド/パスワードをログイン用URLにを送信 Webサーバーが組み合わせを検証 有効な場合、WebサーバーはSession Cookieを発行 ブラウザはSession Cookieつきで会員情報を表示するURLにアクセ
なぜOpenID Connectが必要となったのか、その歴史的背景
タイトル： 『認証の課題とID連携の実装 �〜ハンズオン〜』 概要： FIDO、ID連携（OAuth・OpenID Connect）をはじめとした最近の技術をご紹介します。FIDOは端末とサーバー間でユーザー認証を安全に連携するための仕組みです。OpenID Connectはユーザーの認証と認可を連携するためのID連携の仕組みで、OAuth 2.0を拡張した仕様であり、HTTP通信やJSONなど基礎的なWeb技術によって構成されています。FIDOとID連携の技術を学んだ後、実習ではGolangを用いてWebアプリケーション上にOpenID Connectを実装します。実装の注意点とそのリスク、仕様に施されているセキュリティー対策についてハンズオンを行いながら解説します。 セキュリティ・キャンプ全国大会2019 専門講義 選択コース B4 認証の課題とID連携の実装 〜ハンズオン〜 Aug
idcon 16レポート - mad-pの日記
5月24日に行われた #idcon #16に行ってきました。ヒカリエ21Fの:DeNAセミナールームです。 イベントリンク Ustream togetter 今回はconsumer secretの秘匿、IIW報告などディープな話が聞けそうです。 (19:10) OIDFJからごあいさつ インド、ブッダガヤにいる山中さんから動画が届いています Video Letter from OpenID Foundation Japan & India 江川さんからイベント告知 Enterprise Identity Working Group 7/4 14:00〜 野村総合研究所 丸ノ内総合センター 「公式Twitterアプリに望まれる認証鍵の難読化とリバースエンジニアリング対策(仮)」 @BlackWingCat (黒翼猫) スライド [補助資料] 超軽量Twitterクライアント「もふったー」コン
OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon - r-weblife
おはようございます、ritouです。 今回は、一部で先週話題なりましたOAuth 2.0のImplicit Flowについてのエントリになります。 (2012/2/7 いろいろと修正しました。) 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone Thread Safe: The problem with OAuth for Authentication. 今回は以下の内容について整理したいと思います。 OAuth 2.0のどの機能にセキュリティホールがあるのか 誰が攻撃者になれるのか 対策 OAuth 2.0 Implicit Flowとは OAuth 2.0ではサードパーティーアプリケーションが保護リソースへのアクセス権限を得るためのいくつかのフローが定義されています。 (仕様中ではFlowやGrant Type
GoogleのOAuth 2.0実装におけるToken置換攻撃の防ぎ方 - r-weblife
こんばんは, ritouです. OAuth.jpのnov先生のポストにもある通り, OAuthのImplicit GrantにおけるToken置換攻撃の話や対策についてはFacebookが話題の中心だったりします. この前Google＋の新機能について調べたついでにGoogleのImplicit周りの実装について確認したので, GoogleのOAuthにおいてToken置換攻撃をどのように防ぐべきかを共有します. (中の人でも啓蒙する立場でもなく勝手に調べただけなのであしからず) ClientがWebServerを利用しない場合 : Access Tokenの内容を確認するAPIをたたく Token置換攻撃への対策として必要なのは, Clientが受け取ったTokenが自分用に発行されたものかどうかの確認を行うことです. Googleの場合, Access Tokenの中身を確認するEnd
なんとなくOAuth怖いって思ってるやつちょっと来い - r-weblife
こんばんは、ritouです。 Twitterの問題が発覚した際、こんなgistも書きました。 gist:5053810 · GitHub 今朝、こんなTweetしました。 https://twitter.com/ritou/status/317429458657222657:twitter:detail:left gistに書いた通り、私の考える今回の問題の本質はoauth_callbackの管理、その一言に尽きます。他に2legged OAuthが入るとごちゃごちゃするので、OAuth 1.0の実装のポイントについてまとめてみました。 なんとなくOAuth怖いって思ってるやつちょっと来い from Ryo Ito もちろんこれだけではわけがわからないと思うので、説明が聞きたければどこかで話してもいいです。ぜひ声をかけてください。 普段は秋田にいますが、唯一この勉強会にはよく参加しているの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OAuth 2 and Fragment encoding.
Covert Redirect and its real impact on OAuth and OpenID Connect
http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html
http://tetraph.com/covert_redirect/
Engineering – Foursquare – Medium
なんとなくOAuth怖いって思ってるやつちょっと来い
