事務局ブログ：「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 を、と
瀬戸際に立たされた日本の Webプライバシー
瀬戸際に立たされた日本の Webプライバシー ∼研究者にできることはないのか∼ 独立行政法人産業技術総合研究所 情報セキュリティ研究センター 高木 浩光 電子情報通信学会 情報通信システムセキュリティ研究会 インターネットアーキテクチャ研究会 招待講演 2010年6月17日 （後日配布版） 1 趣旨 •学術界では…… •プライバシー保護技術に関する沢山の研究、問題定義は明白 •しかし現実は…… •最も初歩的な問題ある方式が導入され、放置、継続、拡大 •日本の「ケータイID」の話、ケータイだけで済まなくなる勢い •開発技術者は…… •その方式があたりまえと視野狭窄に •ビジネス界は…… •その方式を前提にサービス設計し始めている •法律家は…… •技術的な違いがわからないまま現行法の解釈論に終始 •どうすればいいの? 2 ケータイIDとは •契約者に固有のID •HTTPの送信ヘッダに挿入
OpenIDにセキュリティ的なプラス面はないか？ - tzmtkのブログ
OpenIDの普及により、セキュリティ的にプラスになる面はないか少し考えてみた。 あるユーザーが認証を行う機会が非常に多くて、ID、パスワードを入力する頻度が高ければ高いとすると、それに比例してフィッシングにひっかかってしまうリスクは増大するという面がある。フィッシングにかかる確率が一定だとすれば、母数が増えるので当然のことともいえるだろう。 また回数が多くなれば多くなるほど、「認証」という行為に対してより意識が低下する傾向もある。 たとえば、認証状態の有効期限をかなり短く設定しておけば、共有のPCなどでうっかりログアウトを忘れた場合などに、他人にIDを乗っ取れてしまうリスクは減らせるが、その一方でいつもID、パスワードを入れていることで、その分そのユーザーは「認証」という行為に無意識になる傾向もある。 また、毎日いろんなサイトにログインして、その度にしっかりログアウトしてセキュリティの意
OpenID Provider のセキュリティ対策 (2) - return_to と realm のチェックを怠るな！ - 日向夏特殊応援部隊
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - Yet Another Hackadelicの続編です。 はじめに RP が認証アサーションリクエストである checkid_setup/checkid_immediate を行う際には通常は return_to と realm を指定します。 return_to とは OP から認証アサーションレスポンスを間接通信で受け取る際に戻って来るURLの事。RP が指定しておく。 realm とは return_to のパターンをワイルドカードを使って表現する。 return_to と realm の検証 基本的に return_to の先は http://openid.art-code.org/handler であるという前提で。便宜上番号振りました。 (1) 期待通りの組合せ real
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - 日向夏特殊応援部隊
やっと下準備終わったので書いてみる。 OpenID でのプトロコルメッセージで、認証アサーション要求*1及び応答*2でのメッセージは通常、RP-OP 間で associate 時に交換した MAC キーを持って署名を行う為、期待する相手と通信している限りは改ざんは起こりにくいと考えられます。 但し最近話題に出て来ている DNS Cache Poisoning のような攻撃を受けた場合、中間者攻撃 (man-in-the-middle attack) が成立する可能性があります。 攻撃手法の例 例えば、RP の DNS が汚染されていた場合を考えます。本来 OP であるはずのホストが悪意のある第三者のサーバーに割り当てられていた場合、その第三者のサーバーが中継を行えば、DH 鍵交換を行ってもまったく無意味で、認証データが盗まれる可能性があります。つまり、 RP から見ると OP に見えて O
OpenIDとリプレイ攻撃 - 日向夏特殊応援部隊
Replay Attackと言うのは、平たく言えばパスワードや暗号鍵、あるいは認証済みのセッションデータ等を再利用してそのユーザーになりすます攻撃の事を言います。 パスワードが漏れるってのは論外だとして、OpenIDの場合はid_resモードのリダイレクトURLが盗聴されていた場合、そのURLを再利用して特定のConsumerサイトでユーザーになりすます事が可能になってしまいます。 元ネタ : http://wiki.openid.net//Replay_Attack_Prevention どうすれば対応出来るか 答えは簡単でConsumer側でnonce(number used once)を使う。 OpenID認証トランザクションの開始時にConsumer側でnonceを発行して、ユーザーのCookieやSessionデータ、あるいはreturn_urlに付与しておきつつ、自前でDBに格
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
