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を使って検証する

mala

概要

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

既存の事例

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

mala

メモ

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

mala

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

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

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

mala

<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

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のケースは「弊社は強固なパスワード暗号化技術を採用しておりますが」と言っている。

mala

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

の続き。

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

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

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

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

mala

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

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

Chromeの場合

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

Firefoxの場合

mala

どういう問題があったか

説明するのめんどい http://vividcode.hatenablog.com/entry/twitter-oauth-vulnerability

どういう対策がされたか

• 第一段階: locationヘッダでの自動リダイレクトからmetaタグでのリダイレクトに変更(X-Frame-Optionsが効くので、iframe総当り攻撃が困難に)
• 第二段階: https://dev.twitter.com/blog/changes-to-sign-in-with-twitter

とりあえず即座に攻撃できるような状態ではなくなっています。

フィッシング？

mala

http://security.slashdot.jp/story/13/02/24/0858210/

Firefox 22のCookieに関するポリシー変更(予定)で具体的にどういう悪影響が懸念されるのかについて書きます。

この変更は「サードパーティCookieをデフォルトでブロック」と言われて想像するものと少し違います。

正確には既にCookieが保存されているドメインであれば3rd party cookieの読み書きを緩和して、新規での3rd party cookieの保存をブロックするというものです。Safariの現行のポリシーとほぼ同じものです。

• 自分は直接的な不利益を受ける立場ではない。
• 自分の所属している企業のWebサイトの多くは広告収益に依存しているが、この変更があっても「巨大な」インパクトは恐らくない。