図解：OAuth 2.0に潜む「5つの脆弱性」と解決法
SNSなど複数のWebサービスが連携して動くサービスは広く使われている。連携に必要不可欠なのが、アクセス権限をセキュアに受け渡すための「OAuth 2.0」といった仕組みだ。今回はOAuth 2.0に関連する代表的な5つの脆弱（ぜいじゃく）性と攻撃手法、対策についてシーケンス図を使って解説する。 OpenID Foundation Japan Evangelistのritouです。 連載第1回では、RFCが公開されてから5年が経過した「OAuth 2.0」を振り返り、3つのユースケースを通じて、アクセス権限を受け渡す仕組みを紹介しました。OAuth 2.0はさまざまなユースケースに適用できます。その際、開発者はアプリケーションが動作する環境の特性を考慮しながら、仕様で定義されている処理を実装する必要があります。 今回は、脆弱（ぜいじゃく）性を作り込まないOAuth 2.0の実装手法を紹介し
事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説（追記あり）
追記 (5/7 20:30): 本文中に「まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。」とありますが、少なくとも Chrome と Firefox はリダイレクト時に URI フラグメントをそのまま保つ (i.e. 不十分な redirect_uri チェック & オープン・リダイレクター & インプリシット・フローの場合、アクセス・トークン入りの URI フラグメントを、ブラウザーがそのままリダイレクト先へのリクエストに用いる) とのことです。続報があり次第追記します。 追記2 (5/7 23:50): John Bradley 氏自身によるフォローアップを訳しました。 Covert Redirect and its real impact on OAuth and OpenID Connect を、と
pixiv Bug Bounty Program 2018 - pixiv inside
こんにちは、セキュリティエンジニアのkoboです。ピクシブでは2016年より脆弱性報奨金制度を運用していますが、2018年度に入ってから報奨金の増額や新しいプラットフォームへの参入など、これまでに増して注力しています。本記事では、最近のピクシブの脆弱性報奨金制度の動向と実際に報告された脆弱性の例を紹介していきます。 pixiv Bug Bounty Programの概要 期間: 2016/04〜 支払い済み報奨金総額: 300万円程度 報告総数: 294件 ピクシブでは2年半ほどに渡って脆弱性報奨金制度を実施してきましたが、2018年に入ってから脆弱性報告の件数、クオリティ向上の為に2つの重要な変更を行いました。 報奨金の増額 脆弱性を報告するハッカーに対してこれまでよりも高いインセンティブを提供することで報告を促すため HackerOneへの参入 世界最大のバグバウンティプラットフォーム
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
ちょっと前に話題になったOpenID Connectの仕様とは？ - r-weblife
OpenID Connectでググってみたものの、紹介記事ばかりで中身を説明してる人があんまりいないようでした。 仕様ドキュメント？かどうかわかりませんが、まともなドキュメントは http://openidconnect.com/ しかありません。 英語読めるエンジニアならこれ読んでだいたいわかってるのかもしれませんが、ざっとまとめておきます。 3行で説明 OAuth 2.0を使って、URL形式のUser Identifierを返す User Identifierは User Info APIとして属性情報取得に利用できる host-metaを利用した独自Discoveryと、DynamicにClient登録のしくみがある 処理フロー OpenID Connect on Web Server Profile シーケンスはこんな感じですね。 ここでは、一番処理の多いケースを考えます。 条件は
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を追加する流れのようです。 これが現状の改善につながれば良いのですが、そう簡単に行かないかもなとも思います。というのも、この問題、なかなかデベロッパーにとって理解されない傾向があります。 そこで今日は、これまでいくつかのアプリデベロッパーに
今更聞けないOAuth2.0
OAuth2.0まとめ speakerdeck はこちら↓ https://speakerdeck.com/satot/jin-geng-wen-kenaioauth2-dot-0#Read less
デスクトップTwitterクライアントアプリでOAuthを使うことの問題点？ - すぎゃーんメモ
発端 [連絡] Termtter の OAuth 機能は廃止の予定 - セキュリティ的な理由から #termtter @jugyo OAuthあまり良くわかっていないですがどういったことが問題になるのでしょうか？ ＞＜ @sugyan Termtter のようなアプリの場合、ユーザーのPCに consumer key 等を置かざるを得なくて、それを使えば誰でも Termtter に成り済ませるんですよね #termtter @sugyan consumer key と consumer key secret を安全に保持する方法が思いつかなかったので OAuth はあきらめることにしました #termtter これ、どんな問題があるかなぁ RT @jugyo: @sugyan Termtter のようなアプリの場合、ユーザーのPCに consumer key 等を置かざるを得なくて、それを
TwitterでPIN番号認証を行う | TechBooster
TwitterでOAuth認証を行う1,2,3ではブラウザからのIntent起動を利用してOAuthを実現しました。 今回はtwiccaなどで使用されているPIN番号(暗証番号)を使用した認証方法を紹介します。 PIN番号認証はIntentを使った認証よりも実装が容易であるというメリットがあります。 詳細は以下から。 サンプルについて この記事でのサンプルはイカのような内容になっています。 ソースコード AuthTwitterActivity.java：PIN番号認証を行うActivity レイアウト auth_twitter_activity_start.xml：認証用ブラウザを開くための同意画面 auth_twitter_activity_type：PIN番号認証を行う画面 アプリケーションをTwitterに登録する Twitterと連携したアプリケーションを作成するにはTwitter
もふったーをハックしたら予想以上に酷かった件 - kusano-k’s blog
TweetDeck をハックしたら予想以上に酷かった件 - Windows 2000 Blog もふったーの作者が、TweetDeckがConsumer keyとConsumer secretを平文で持っていることを批判していたので、もふったーはどうなっているのか調べてみた。 もふったーをインストールする Immunity Debuggerをインストールする Immunity Debuggerでもふったーを開き、下の画面のようになるまで、F9を押して実行する CPUウィンドウの左上の欄で右クリック → Search for → All referenced text strings 出てきた画面で右クリック → Search for text → 「consumer_key」で検索 oauth_consumer_keyをダブルクリック → F2を押してブレークポイントを設定 → F9を押し
TweetDeck をハックしたら予想以上に酷かった件 - Windows 2000 Blog
3rdに引っ越しました。 2010/12/31 以前＆2023/1/1 以降の記事を開くと５秒後にリダイレクトされます。 普段の日記は あっち[http://thyrving.livedoor.biz/] こちらには技術関係のちょっとマニアックな記事やニュースを載せます。 Windows2000ネタ中心に毎日更新。 【拡散希望】twitterの新型ウイルスがヤバい URL踏んだだけでアウト - uinyan. com Twitter で TweetDeck Tweetbot for iOS HootSuite iOSのデフォルトアプリ ShootingStar/Pro 等のコンシューマキーが流出して、それを利用したウィルスが猛威を振るってたようです ためしに、 Tweet Deck でコンシューマキーとコンシューマシークレットキーが抜き出せるか試してみました まず、アプリケーションを起動し
特定のクライアントを許可している Twitter ユーザーの Token Credentials を入手する攻撃 - ひだまりソケットは壊れない
怪しいクライアントを許可していないのに勝手に twitter で DM が送信されていた 何やら Twitter で勝手に DM が送られるという事案が発生していた模様。 調査の結果、ある web ページにアクセスしただけで、Twitter の token credentials が攻撃者に知られてしまう *1 ということがわかったらしい。 下記ページにまとめられていたのだけどパッと読んですぐには攻撃手法を理解できなかったので、いろいろ考えたことを書き残しておく。 「ちょっとこれみてくれない」とurlを送るスパムDMの解析と解説 - Togetter 簡潔な解説が以下の記事にあったので、簡潔な説明で理解できる人は下記記事参照。 gist:5053810 (DM踏んだだけでアレな件はTwitterのOAuth実装がク○だと思う) 【拡散希望】twitterの新型ウイルスがヤバい URL踏んだ
OAuthの認証にWebViewを使うのはやめよう
AndroidからTwitterへアクセスするためのライブラリとして，Twitter4Jが有名です． これを使ってみようと，「Android Twitter4J」と検索すると 認証にWebViewを使った例がたくさん出てきます． ・・・いや，ちょっとまて． それはちょっとまずいだろう． そういうわけでもうちょっと賢い方法を探してみました． 何がまずいのさ 「Android Twitter4J」と検索すると，上位にこんなページが出てきます． Twitter4jを使ってOAuth認証をアプリ内で行う方法 Twitter4j-2.2.xを使ったOAuth認証のコーディング例 twitter4jでツイートする Android+Twitter4JでOAuthするためのソースコード 上のサイトでは次の様は方法をとっています． アプリ内にWebViewを貼り付け WebViewでTwitterの認証画面
The OAuth 2.0 Authorization Protocol
The OAuth 2.0 Authorization Protocol draft-ietf-oauth-v2-22 Abstract OAuth 2.0 は, サードパーティーアプリケーションがHTTPで提供されるサービスとリソースオーナー間に同意の調整を行うか, もしくはサードパーティーアプリケーション自身のためにアクセスすることを自ら許可することによって, サービスへの限定されたアクセス権を得ることを可能にする認可プロトコルである. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Intern
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【セキュリティ速報】OAuthの欠陥！？ Covert Redirect 脆弱性についての簡単な解説：こうしす！通信
http://tetraph.com/covert_redirect/
TwitterのOAuthの問題の補足とか
