- SOP bypass どこから脆弱性？
- SOP bypassと呼ばれる脆弱性
- 報告した問題いくつか
- 「脆弱性」だと認識されない問題について
- cross originでの通信を許可するには？
- JavaScript: CORS header
- Flash: crossdomain.xml
- Java,Silverlight: also supported crossdomain.xml
- CORSの場合
- リクエスト発行のタイミングの場合
- リソースの読み取りのタイミングの場合
- 両方あります
- カスタムヘッダ付与: リクエスト発行前にチェック、preflight requestが必要
- 単純なリソース読み込み: リクエスト発行後にチェックされる。
- CORSはリソース単位であるのに対して
- crossdomain.xmlはドメイン全体に対する包括的な許可
- Custom headerをcross originで送信可能だった問題
- https://bugzilla.mozilla.org/show_bug.cgi?id=573873
- 2011年
- http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails/
- disclosure: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html
- Ruby on RailsがカスタムヘッダのチェックによるCSRF対策を行っていた
- Flashを使った迂回方法があったため、Rails側の脆弱性として修正される
- Flashは、2011年にこの問題が既に知られていたが、2014年まで直らなかった。
- この問題は、FlashとBrowser両方の対応が必要だった。
- pluginにredirect statusを伝えるための仕様の欠如
- ブラウザ本体のsame origin policyとの食い違いが起きている
- CORSで仕様が整理されてきて問題が明確になってきた
- 何が出来て良いことで何が出来てまずいか
- UXSS: 強い、他のdomainの権限でscript実行
- Read contents, cached contents: 読み込みが可能
- POST only: 本来preflightが必要なrequestが実行可能
- leak information: その他の本来取れない情報が取れる
- 昔は ユーザー操作が必要だった
- 今は JavaScriptのみで可能
- Flashの方が厳しい: http://www.adobe.com/jp/devnet/flashplayer/articles/fplayer10_security_changes.html
- http://yoshiweb.net/blog/?itemid=476
- http://cda244.com/2011/08/26-56/
- get byteArray by LoaderInfo.bytes
- Flashでcrossdomain.xml不要で画像をデータとして読み込むテクニックが知られていた
- 「裏技」として認識 → それ脆弱性だから！！！
- バグか脆弱性か？
- 出来て良いことと悪いことの区別が難しい
- 「脆弱性」として認識されないことも多い
- 自分が報告したもの
- SafariのSOP bypass (URL偽装、cache読み取り)
- FlashのSOP bypass(サイズ読み取り、リダイレクト判定)
- Safari, WebKit based browser.
- 30x redirect がキャッシュされた場合の処理がおかしい
- URLが置き換わらない
- iOS developer曰く「Safariの仕様？」
- 異なるサーバーにリクエストが飛んできている。
- → それ仕様どころか確実にバグだし、脆弱性になるから！
- 調査を開始 → 再現条件の特定、悪用方法を考える
- 限定的だが外部originのキャッシュ読み取りに使える → URL偽装とSOP bypass
- reported by mala / not fixed yet.
- Cross originでの読み込みが本当に制限しているか確認している途中で発見
- 外部リソースロード時にProgress Eventが発生している
- 出来てはいけない根拠 https://www.w3.org/TR/progress-events/#security-considerations
- SOP bypass としては「弱い」
- リダイレクトしているかどうかで、ログイン済みかどうかの判断が可能
- https://github.com/RobinLinus/socialmedia-leak SocialMedia fingerprint
- login後のredirect pathの制限 → 画像にリダイレクトしないように という対策が一部のサイトで行われる
- それ無意味だから！！１
- サイズ推定による攻撃
- httpsのサイトでファイルサイズが正確に取れる
- ファイルサイズ自体がセンシティブになるようなケース？
- 同じURLでもユーザーごとに違うレスポンスを返すようなケース
- サイズに特徴があれば、ユーザーidの推定に使える
- 圧縮率の変化でコンテンツ推定は、SSL/TLSの脆弱性として知られる
- gzip伸長後のサイズが返ってくるため、圧縮率を使った攻撃はあまり効果的ではない
- MITMと組み合わせればヒントとしては大きい
- crossdomain.xml で許可されていれば、取れる
- auth.sns.example.com/my/picture → cdn.public.sns.example.com/userid/profile_image.jpg
- こういうのがあればユーザー推定に使えそう。(見つけていない)
- リダイレクト先のドメイン部分 → 許可が無くても、取れる。
- auth.sns.example.com/my/picture → username.sns.example.com/ ?
- Flashのバグ残ってるとどうしようもない
- 直ったとしてどこまで対策すべき？
- 露骨にユーザー毎に異なる画像へリダイレクト、などはやめましょう
- ユーザーIDの推定 > ログインしているかどうかの推定
- それ以上は対処が困難、大手サイトも未対応
- あなたは正確に説明できますか？
- 画像サイズ
- ロード時間(onload,onerror発生まで)
- window.name, window.parent.postMessage
- etc
- コード実行のゼロデイ攻撃などは優先対応
- 「弱い」SOP bypassは修正に時間がかかる
- 修正されないかもしれない
- cross originのリソース読み込みでProgress
- → 実際に使われている？代用がなく廃止が難しい
- Flashの死を待ちましょう
- デフォルト無効化へ
- SOME (same origin method execution)
- Flashのjs callback指定
- 任意jsは実行できないが、window.opener.xxx 既にある関数の呼び出し
- form submitでCSRFに利用 → 脆弱性に昇格
- cross originで出来てまずいことが出来たらSOP bypass
- UXSSまで行かなくても、他の問題との組み合わせで脆弱性に
- 本来出来てまずいことが、平然と出来ていたことがあった。
- 今だとCORSで仕様が整理されて脆弱性だと明確に。