ClickJacking関連：後半は流し読みレベル。
- IPAから「クリックジャッキング」に関するレポート出ました | 徳丸浩の日記
-- http://blog.tokumaru.org/2013/03/clickjacking-report-by-IPA.html
- 情報処理推進機構：IPA テクニカルウォッチ：知らぬ間にプライバシー情報の非公開設定を公開設定に変更されてしまうなどの『クリックジャッキング』に関するレポート
-- http://www.ipa.go.jp/about/technicalwatch/20130326.html
- Clickjacking - OWASP
-- https://www.owasp.org/index.php/Clickjacking
- SecTheory - Internet Security
-- http://www.sectheory.com/clickjacking.htm
- CSRF, Clickjacking, and the Role of X-Frame-Options » Neal Poole
-- https://nealpoole.com/blog/2012/03/csrf-clickjacking-and-the-role-of-x-frame-options/
- Attack and Defense Labs: Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
-- http://blog.andlabs.org/2010/03/bypassing-csrf-protections-with.html
- My InfoSec Ramblings: XSS vs CSRF vs ClickJacking
-- http://ardsec.blogspot.jp/2010/08/xss-vs-csrf-vs-clickjacking.html
- hackademix.net » Clickjacking and NoScript
-- http://hackademix.net/2008/09/27/clickjacking-and-noscript/

OAuthのConsumerKey/ConsumerSecretの扱いについて：
- Authentication & Authorization | Twitter Developers
-- https://dev.twitter.com/docs/auth
--- OAuth signed, application-only auth, Basic authの3種類ある。

OAuth 1.0aベース：
- Obtaining access tokens | Twitter Developers
-- https://dev.twitter.com/docs/auth/obtaining-access-tokens
--- 3-legged OAuth
--- xAuth : Twitter版の2-legged OAuthみたいな感じ？
---- https://dev.twitter.com/docs/oauth/xauth

Application-only authentication : OAuth 2.0, Client Credentials Grant を実装
- Application-only authentication | Twitter Developers
-- https://dev.twitter.com/docs/auth/application-only-auth

xAuthに関連して、OAuthでは3-leggedと2-leggedと呼ばれる二種類がある。
- 3-legged : EndUser - Consumer - ServiceProvider の3者が関連する、OAuth Coreで定められているフロー。
- 2-legged : Consumerが特にEndUserと紐付かない状態でServiceProviderを利用するために OAuth Consumer Request という名前で拡張されたフロー。
-- Implementers' Draft: OAuth Consumer Request 1.0 Draft 1
--- http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/1/spec.html
-- OAuthの仕様について 〜署名？それっておいしいの？〜 - Yahoo! JAPAN Tech Blog
--- http://techblog.yahoo.co.jp/web/auth/oauth_1/
-- OAuth Consumer Request の処理フローと実装 | Weboo! Returns.
--- http://weboo-returns.com/blog/django-oauth-consumer-request/
-- OpenSocialのOAuthまとめ – Tender Surrender
--- http://devlog.agektmr.com/ja/archives/79
-- 2-legged OAuthによるAPIアクセス << mixi Developer Center (ミクシィ デベロッパーセンター)
--- http://developer.mixi.co.jp/appli/ns/mob/2-legged-oauth/

今現在ホットなConsumerKey/ConsumerSecretのモバイルやデスクトップアプリケーションでの取り扱い周り
- create desktop application | Twitter Developers
-- https://dev.twitter.com/discussions/1758
--- ちょっと古い。2012年の話題。
- How do I store the OAuth v1 consumer key and secret for an open source desktop Twitter client without revealing it to the user? - Programmers
-- http://programmers.stackexchange.com/questions/99295/how-do-i-store-the-oauth-v1-consumer-key-and-secret-for-an-open-source-desktop-t

TwitterのConsumerKeyガー、ConsumerSecretガー、と騒動になった件の、顛末らしきまとめ。
- なんとなくOAuth怖いって思ってるやつちょっと来い - r-weblife
-- http://d.hatena.ne.jp/ritou/20130329/1364557605
- https://gist.github.com/ritou/5053810
- https://twitter.com/bulkneets/status/316842380194107392
-- すみません、有害な側でした。
- https://gist.github.com/mala/5062931
- https://gist.github.com/mala/5107120
-- あまりにも分かりやすくてわざわざ質問した自分が馬鹿だった。っていうかこのGist知らなかった自分の情報収集能力を疑う。

単純にConsumerKey/Secretが漏洩しただけでは危険とは断定できなくて、ServiceProvider側のcallbackの取り扱いであるとか、認可画面のClickJacking対策とかが絡みあって結果として脆弱な状態になってたみたいです。下手に状況を説明するとどこかで間違ってる可能性があるので詳しくは上のmalaさんとかritouさんのGist読む。

Twitterの件が関連してたのかどうか分かりませんが、ClickJackingの話もタイムリーにIPAから出て来ましたので、これを機会に色々と復習します。