UDIDにおけるセキュリティ＆プライバシー問題
これまでの連載では「OAuth」と「OpenID Connect」について紹介してきましたが、今回は少し趣向を変えて、UDIDについてお話しします。 これまでの連載では、「OAuth」と「OpenID Connect」について紹介してきました。今回は少し趣向を変えて、UDIDについてお話ししようと思います。 UDID（Unique Device Identifier）とは、その名の通りデバイスに固有に割り振られた識別子のことで、具体的にはiPhone/iPadのデバイス識別子のことを指します。このUDIDは本来、米アップルが出荷したデバイスを識別するために割り振ったものです。 しかし、ガラケー時代に広まった、契約者固有番号や端末識別子を用いて認証する「かんたんログイン」方式を、UDIDを用いてそのままiOSアプリにも適用する事業者が増え、多くの問題を発生させてきました。今回は、こうしたUD
「OAuth 2.0 (Implicit Flow) でログイン」の被害例 - OAuth.jp
。登場人物 OAuth 2.0対応してる某ゲームプラットフォーム 某ゲームプラットフォーム上で占いゲームを運営してる攻撃者 某ゲームプラットフォーム上で農園ゲームを運営してる被害アプリの開発者 某ゲームプラットフォーム上で無邪気に遊んでる被害ユーザ ※ 念のため、今回の話は特にゲームに限った話ではない。 前提 某ゲームプラットフォーム、農園ゲーム共に、XSS とか CSRF とかセッションハイジャックされるような脆弱性はない。 農園ゲームはプラットフォームが発行するAccess TokenをOAuth 2.0のImplicit Flowを使って受け取り、同じくプラットフォームが提供するProfile API (GET /me とか) にアクセスして、レスポンスに含まれる user_id をもとにユーザを認証している。 攻撃者は占いゲームのDBから任意のAccess Tokenを取得可能。
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20090801/p01/
