OAuthに対するWPAD/PAC攻撃と対策
8月3日のBlackhat 2016で発表された、HTTPSのURLが読めるというWPAD/PAC Attack1、なるほどねぇ、と思わせるアタックですな。 HTTPS自身を攻撃するわけじゃなくて、HTTPSのhostに対するproxy resolveの時に、PACファイルを使ってURLの内容をフィルタリングして攻撃者のホストに送るというやり口。 毎回proxy resolveが走るブラウザ（例：Firefox, Chrome）とそうでないブラウザがあって、後者だとあまり攻撃は成功しないが、FirefoxやChromeなどでは効果的。ただし、LANのProxy設定などで、「設定を自動的に検出する」がオンになっていなければならない。でもこれは、企業システムなどでは割りとONになっていることが多いのではないだろうか。
OAuth PKCEがRFC7636として発行されました。
私とJohn Bradley(Ping)とNaveen Agarwal(Google)が共著者としてクレジットされている「OAuth PKCE（ピクシー）」 が、[RFC 7636] として発行されました。元々はOAuth SPOP (Symmetric Proof of Posession)と言っていたものですが、Symmetricに限らない形に拡張したため、Proof Key for Code Exchange (PKCE、ピクシー＝妖精）と名を改めて現在に至っています。 この規格はOAuth 2.0 [RFC6749]のPublic Client の Code Interception Attack 脆弱性に対応するもので、ephemeral keyを生成して、これを使ったProof of Possession of Key をします。RFC6749と後方互換性がありますし実装も簡単
「番号」設計のあるべき姿 〜 年金番号漏洩事件によせて
年金番号漏洩事件では、「漏洩した番号は全て変更する」のだそうです[1]。個人的には「あーあ」という感じでありんす。昨日の記事[2]でも書いたとおり、適切に運用していれば、番号自体の漏洩は大したリスクではなく、一緒に漏れた住所氏名他が変えられない以上、年金番号だけ変えてもあまり意味が無いからです。 逆に、設計の古い年金番号は、変えるとなると、連動して変えなければいけないところがあった場合にうまく変わらないことが想定され、そのことがかえって被害を産む恐れもあります。 「番号」（本当は識別子と呼ぶべきですが、ここでは便宜的に「番号」と呼びます）の設計というのは、想定される利用形態によって様々な考慮点があります。したがって、『「番号」設計のあるべき姿』はある意味ケースバイケースということにはなります。しかし、一方では、最低限満たすべき要件というものもあるのですね。 という訳で、ちょっとリストアップ
Specifications – 仕様集
現在作業中の仕様集 OpenID Connect 関連仕様 規格化済 OpenID Connect Core – OpenID Connect の基本部分 OpenID Connect Dynamic Registration – (Client を動的に登録するための仕様 OpenID Connect Discovery – Server Endpoint および設定情報を動的に発見するための仕様 例：Google https://accounts.google.com/.well-known/openid-configuration OAuth 2.0 Multiple Response Types –OAuth 2.0 response_type に OpenID Connect利用するものを追加. OpenID 2.0 to OpenID Connect Migration 1.0
単なる 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ページを開く
