mala mala

一瞬popup + 以降iframeでproxyするようなもの。XHR level2いらないのでやや動作環境が広がる。

クライアント側ボタンクリックで window.open + ランダムなid(これをclient_id相当にする)の名前をつけてiframe埋め込み
popup windowにiframeの名前をpostMessageで送る
サーバー側: popup windowはiframeに対してpostMessageで返信(event.source.frames.xxxx)、api-domainのoriginであることを確認、cookieで認証してランダムなidとセットで使えるトークン発行
トークン保存はmemcachedなど揮発性のストレージで良い。使っている限り期限が延長される。最長期限があってもよい(あったほうがよい)
ログアウトとセットで破棄されるようになっていると良い
iframeはポップアップwindowからメッセージを受け取る。ランダムなid + トークンを使ってAPIにアクセスする。
iframeは親windowからメッセージを受け取る。あとはpostMessageでproxyしてXHRのリクエスト、レスポンスをやり取りする。
iframeは親windowからのメッセージであることをevent.originを使って検証する

概要

フィードを更新するためのAPIがあると便利です
クローラを別ホストで動かしたり、別言語で書いたり、特殊用途向けのクローラが書きやすくなります。
管理者向けメリット: クロールを外部サービスに分離できる
ユーザー向けメリット: APIに直接POSTしてフィードじゃないものを読めるようになる
サイト運営者向け: 将来的なこと考えるとフィードを各々好き勝手クロールする状況は効率が悪い → 更新のタイミングでPush

既存の事例

Bloglinesには専用のメールアドレスを発行してそこにメール送るとフィードとして読めるみたいな機能があった。
メール送る → 読めるシンプルで万国共通、でもSMTPは面倒くさい

Evernoteの話ですけど。「強固なパスワード暗号化技術を採用」していて、攻撃者がまず生パスワード復元できないだろう、という状況であっても、パスワードリセットはしたほうがいい。

2011年のLastpassのケースでは、強固なパスワード使っている人は大丈夫だけど、そうじゃない場合はブルートフォースでマスターパスワード取得されうるということを発表していた。これはハッシュ値生成のアルゴリズムが、既知 or 推測しやすい or ソースコードも含めて漏洩している、という時にこの状態になる。

http://blog.lastpass.com/2011/05/lastpass-security-notification.html

"If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing."

で、Evernoteのケースは「弊社は強固なパスワード暗号化技術を採用しておりますが」と言っている。

https://gist.github.com/mala/5062931

の続き。

Twitterの人に色々と問題点は伝えたんだけど、これからOAuthのサーバー書く人や、クライアント書く人が似たような問題を起こさないようにするために、どうすればいいのかについて簡単に書きます。既存の実装真似して作るとうっかりひどい目にあう。

自分は意図的に「Twitterの脆弱性」という表現を使わないように気を使っていて、それはクライアントアプリ側の責任もあるからなのだけれども、安全に実装するための方法がわかりにくかったり誤解を招きやすかったり、Twitterに買収されているTweetDeckにも問題があったりしたので、それはやっぱりTwitter側の責任の比重が大きいとは思う。とはいっても別に責任を追求したかったり◯◯はクソだといったことを言いたいわけではなく、誰が悪いとか言う以前に、複合的な要因によって問題が起きるときには原因を正しく理解する必要があると思う。

そもそも何を担保に安全性を保証しているのか

サーバー側で秘密の鍵を持っている(それが無いとアクセストークンを取得できない or 使えない)

検証環境 Firefox19.0 / Chrome 27.0.1425.0 / Safari 6.0.2

攻撃サイトとして報告されているURLを(hosts書き換えて) 読み込むとどう反応するか。それぞれアドレスバーに直接入力だとブロック。

Chromeの場合

画像: リクエスト自体行わない、派手な警告を出す
script: リクエスト自体行わない、派手な警告を出す
iframe: リクエスト自体行わない、派手な警告を出す

	概要
	WordPressが修正したつもりになってたSWFUploadのXSSの修正方法が不完全で最新版でもまだある。
	http://wordpress.org/news/wp-includes/js/swfupload/swfupload.swf#?movieName=SWFUpload_0&buttonText=%26lt%3Ba%20href%3D'javascript%3Aalert(location)'%26gt%3Bclickhere%26lt%3B%2Fa%26gt%3B

	----
	届出ステータス
	- 2013-04-24 security at wordpress.org
	- 2013-04-25 IPA, Neal Poole氏

	----

	メモ

	全体的なこと
	- 想定してるRubyとかRailsのバージョンが古いので何とかしたい。
	- 個人的に改造してる人がそれなりにいるので、その辺まとめたい。
	- github/livedoor もあるんだけど、そこにadmin権限持ってるユーザー好き勝手追加は怖いので別で + コミュニティ主導でやりたい
	- html/js/css も割と古くなってしまっているので、そのへんも何とかしたい。
	----
	オープンソースに拘るのは保険的な意味合いもあるのだけど、
	サービス型のRSSリーダーで出来無いことがそれなりにあるというのが大きい。

	https://bugzilla.mozilla.org/show_bug.cgi?id=844622#c6

	CORSのwithCredentials付いてるときはどうする、という話題

	ジョナサンメイヤー:
	「new policyと同様に、既にcookieを持ってるなら緩和する、これでいいんじゃないの」
	「もう一つはwithCredentials付けてる時にはcookieの新規セットを緩和するようにする案。
	これは良くないアプローチだし、そもそも必要かどうかわからないが。サードパーティCookieをセットする抜け穴になるだろう。
	Safariのフォーム送信のように。Safariではいくつかのウェブサイトがそれを濫用した。」

	<script>
	var now = Date.now();
	var phishing;
	var malware;
	var p_loaded = false;
	var m_loaded = false;
	</script>
	<script src="http://www.mozilla.org/firefox/its-a-trap.html" onerror="phishing=Date.now()-now;p_loaded=true"></script>
	<script src="http://www.mozilla.org/firefox/its-an-attack.html" onerror="malware=Date.now()-now;m_loaded=true"></script>
	<script>

mala mala

概要

既存の事例

そもそも何を担保に安全性を保証しているのか

Chromeの場合

Firefoxの場合