金利0無利息キャッシング – キャッシングできます

|

2013-07-18

FlashのloaderInfo.parametersがhash fragmentでも受け取っちゃう問題が修正された

20:26 | FlashのloaderInfo.parametersがhash fragmentでも受け取っちゃう問題が修正された - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - FlashのloaderInfo.parametersがhash fragmentでも受け取っちゃう問題が修正された - 金利0無利息キャッシング – キャッシングできます

http://subtech.g.hatena.ne.jp/mala/20130604/1370328781 で書いた #? 以降の文字列をloaderInfo.parametersで受け取ってしまう件が7月9にリリースされたFlash Player 11.8.800.94 で修正されました。

リリースノートには特に書いてないっぽいです。この件とは無関係に重要なsecurity fixが含まれているとのことなのでアップデートしたほうが良いです。

この変更によって "証拠を残さずに" Flash based XSS攻撃を仕掛けることができなくなりました。証拠残してもいい人は引き続き出来ます。既存のswfファイルが勝手に安全になるわけではありませんが、swfの修正が困難な時や、使っているswfが安全かどうか分からない場合に、みんな大好きmod_rewriteで対処することが出来るようになりました。古いFlash Playerを使ってる人は救われないことになりますが、古いFlash Playerを使っている人はどのみちもっと深刻な問題があるので、あまり気にしないことにしましょう。

例えばこんなので

RewriteEngine on

RewriteCond %{REQUEST_URI} ^/swf/.*
RewriteCond %{QUERY_STRING} ^.*=.*$
RewriteRule / / [F,L]

/swf/hoge.swf?key=value 的なURLだった場合に問答無用で403を返すといったことができます。

トラックバック - http://subtech.g.hatena.ne.jp/mala/20130718

2013-06-04

Flash Based XSSについて その1 事例

15:52 |  Flash Based XSSについて その1 事例 - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク -  Flash Based XSSについて その1 事例 - 金利0無利息キャッシング – キャッシングできます

直ってないのとか影響が大きいのとかあるので、あとで書く。 → 書いた。

事例集です。

全体的な話

  • 正直ブラウザかFlash Player側でなんとかしたほうが良いと思っている。
  • 特にFlash Playerにはセキュリティ上、不適切な仕様がいくつかある。

発見方法や修正方法はこちらに書いた http://subtech.g.hatena.ne.jp/mala/20130604/1370328780

HTMLJavaScriptの補完としてパーツとして使われるswfファイル、アップロード、ビデオ再生、クリップボード制御など、パラメータが決め打ちではなく柔軟にカスタマイズ出来るようになっているようなものに、こういった問題が含まれてしまうことが多い。flashvars経由で「のみ」信頼できるパラメータが入力されるはずだと想定したものが、URL経由で外部から自由にパラメータを指定できるようになっている。とにかく探せば見つかるという状態になっているし(報奨金もらえるようなところは既に対応されてることが多いと思うけど) 古いバージョンのまま放置されているということが多い。

MEGA Facebook Yahoo!

著名なWebサイトで報告されてる事例とか。

Facebook

ビデオプレイヤー

Yahoo

Yahoo Mailで使われているswfXSSを報告したのだけれど

別件で他の人も見つけて報告していた。

Yahoo!のTシャツは非常にクール。

MEGA.co.nz

クリップボードコピー機能のExternalInterface.call呼び出し箇所でXSS

ライブラリ等の事例

色んなサイトで使われててソース公開されてて修正箇所が分かるものの事例。

SWFUpload

2012年5月に開示されている。

このタイミングでおそらくはSWFUploadにも報告されているのだけれど、詳細は公開されなかったし、WordPressが加えた修正も逆コンパイルしないと分からない状態だった。

その結果、CVEでは「詳細不明の脆弱性」として取り扱われている。

CVEを受けて、swfuploadは、Debianが独自でパッチを当てて配布するなどしていた。

実はこの修正は不完全で、その後、buttonTextパラメータを使ってXSS出来るものも開示された(要ユーザー操作、クリックジャッキングとの組み合わせはありうる)

2012-12-31

2013-03 にはFull disclosureに投稿あり

(この MustLive って人がめちゃくちゃ色んなプロジェクトに報告してる)

Neal Poole氏が2012年5月にブログに書いた際には、buttonTextを使ったパターンについては含まれていなかった。WordPressは別の人からbuttonTextを使ったパターンについても報告を受けていたはずなのだけれど、MustLive氏は3.3.2で修正されたって書いてあるんだけど、WordPressの修正方法に問題があって、かつ、詳細が開示されなかったため問題の一部しか修正せずに「修正したつもりになっている」forkが生まれ、WordPressは不適切な修正のまま1年以上が経過することとなった。

WordPressに修正方法が間違ってるよって報告して、その後しばらく動きがなかったのだけれど、3.5.2で修正された。

自分の名前が載ってるのはこの件 http://ja.wordpress.org/2013/06/22/wordpress-3-5-2/

WordPress本体は「既にSWFUploadを使っていない」のだけれど、Pluginから使われていることがあるので引き続き同梱している。

で、影響の大きさを鑑みて、secureなバージョンを作ってメンテしていくことになった。使用を推奨しないけれど、どうしても必要であればこちらをどうぞ、という具合。

バージョンアップしてないサイトがまだ大多数だろうから、具体的な攻撃コードは(しばらく)公開しないけど、逆コンパイルして注意深くソース読めば分かる。というか多分他にもクリティカルな問題色々含まれているだろうから、swfXSSはともかくバージョンアップしたほうが良いと思う。対象はWordPress使用サイト全般。

JWPlayer

有名所ではOctopressがこれを同梱している。

具体的にはこんなん http://ja.mhatta.org/assets/jwplayer/player.swf?#&debug=alert%281%29

Octopressに報告して代わりのビデオプレイヤーを探していたところ代用に使おうとしたライブラリにことごとく同様にXSSの問題があって、おいおい安全なビデオプレイヤーが全然無いじゃねーかよ、ファック、みたいな感じになっていた。対象はOctopress使用サイト全般。多分殆ど静的サイトだろうから影響は少ないと思うけど重要な情報扱うドメインと同居している場合には注意、videoプレイヤー使ってない場合はjwplayerを削除してしまって良い。Octopress使用するような層は自力で何とか出来るでしょう。

JWPlayer6はどういう修正をしているかというと、URLから指定されるパラメータを、そもそも受け取らないようにした。

ちなみに3.x系列から5.xまで全てのバージョンでXSSがある。

VideoJS

FlowPlayer

  • 純粋にFlashのものと、HTML5 videoタグを使おうとするものの二種類ある。
  • ver 3.x 系列 Flashのみ
  • ver 5.x 系列 videoタグにFlash fallbackを加えたもの。HTML5 version.

両方に問題があり、それぞれ自分が報告した。ver 3.x系列については既に把握していたようだった。

HTML5 versionについては修正された。

2013-11-08追記

ちゃんと直ってなかった。報告はしてるけど修正されていない。いつ直るか不明。URL中のcallback=を禁止してるのでパーセントエンコードした状態で渡すと素通しになってしまっている。

https://github.com/flowplayer/flowplayer/issues/381#issuecomment-27564871


3.x系列については今のところ修正予定がないようなので、置き換えることを推奨する。

MediaElements

これは単なる偶然なのだろうけど、自分の知る限り、Google Chromeでしか動作しなかった。

ExternalInterface.objectID が セットされている場合のみExternalInterface.callが呼ばれるためで、Chromeの場合、swfを直接開いた場合の埋め込みタグは以下のようになっていて

<embed width="100%" height="100%" name="plugin" src="..." type="application/x-shockwave-flash"> 

name="plugin"によってExternalInterface.objectIDが"plugin"にデフォルトでセットされた状態になる。

ZeroClipboardの事例

ZeroClipboardを同梱しているzClipというのがあり。

こちらにも連絡したけど特に直ってない。ZeroClipboardを同梱している場合には、古いバージョンが使われていないかを調べる必要がある。

Uploadify

ファイルアップロードのswf、swfuploadの派生。大きく告知されていないが、7/5にリリースされているUploadify 3.2.1でswfuploadが差し替えられている。

ちなみにこれ報告したの自分でbug bounty programで$400もらった。

http://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-004579.html

fancyupload

ファイルアップロードのswf、fireCallbackに任意の関数名を指定可能。連絡しているが応答無し。

https://github.com/digitarald/digitarald-fancyupload/blob/master/source/as3proj/Main.as#L142


TODO

他にも影響大きそうなのあったら書く。

2013-11-08追記

JWPlayer過去バージョン、flowplayer、Uploadify、fancyuploadについて追記。

Flash Based XSSについて その2 解析と発見と修正方法

15:53 |  Flash Based XSSについて その2 解析と発見と修正方法 - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク -  Flash Based XSSについて その2 解析と発見と修正方法 - 金利0無利息キャッシング – キャッシングできます

Adobe SWF Investigator

Adobe謹製のswf調査ツール

http://labs.adobe.com/technologies/swfinvestigator/

使ってない。

JPEXS Free Flash Decompiler

http://www.free-decompiler.com/flash/

最近はもっぱらこれを使っている。コマンドラインからもswfのエクスポートが出来るのでswfファイルまとめてas3エクスポートしてack or agで怪しそうな箇所調べる。

ActionScript ByteCodeを差し替えるという機能があるので、ソースがないswfでも修正することが出来る。ActionScript ByteCodeを手書きするのは、つらい。

SWFTOOLS

http://www.swftools.org/

Flash持ってないし高いし不自由なソフトウェアをなるべく使いたくないしActionScript ByteCode手書きするのはつらいので、Flashデベロッパー各位においてはとにかくas3compileでメンテ出来る状態でソースを残しておいて欲しい(欲しかった)

ffdecを使ったswfの脆弱性の探し方

./swf/ にダウンロードしたswfファイルがたくさんあるとしてこんなかんじでモリモリとデコンパイルできる。

ls swf/ | xargs -I {} ./ffdec.sh -export as ./out/{} ./swf/{}

そうしたらgrep -rでもackでもagでもお好きなもので ExternalInterface loaderInfo Loader .load( htmlText navigateToURL とか探す。

確認したほうが良い箇所は

  • loaderInfoで外部から入力されてるパラメータを調べる(変数に代入してたら覚えとく)
  • ExternalInterface.call に渡している関数名、引数が外部入力に起因していないか
  • xxx.load(url, ..) となってる箇所で外部ドメインのリソース(特にswfムービーとXML)をロード可能になってないか
  • htmlTextに代入する文字列でa href=javascript:なリンクを作れる状態になってないか
  • navigateToURLでjavascript: に遷移可能な状態になってないか

応急処置的直し方

Flashのソースが無いとか開発環境がないとか、そういう状況でとにかく何とかしたいときに、応急処置的になんとかする方法がいくつかあるので紹介する。

ffdecを使う場合

まずはffdecを使ってswfを直接編集する方法。swfを表示した際のURLに ?.*= が含まれていたら問答無用でエラーにするという方法がある。これをやると some.swf?nocache=1370414777222 みたいに日付とか乱数付与してロードしている場合にもエラーにしてしまうので注意。

現状、ffdecはas3のコードを直接書くことは出来ない。

のだけれど、bytecodeの差し替えができるようになっている。デコンパイル後のソースで

var _loc2_:* = new RegExp("\\?.*=","i");
if(_loc2_.test(LoaderInfo(param1.loaderInfo).url))
{
throw "security error";
}

に相当するコードを書きたい場合には、

getlex m[nnn]"RegExp"
pushstring "\\?.*="
pushstring "i"
construct 2
setlocal 2
getlocal 2
findpropstrict m[nnn]"flash.display.LoaderInfo"
getlocal_1
getproperty m[nnn]"loaderInfo"
callproperty m[nnn]"flash.display.LoaderInfo" 1
getproperty m[nnn]"url"
callproperty m[nnn]"http://adobe.com/AS3/2006/builtin.test" 1
iffalse ofs00nn
pushstring "security error"
throw
ofs00nn:nop

のようにすればいい。getlex m[nnn]と書いてあるnnnの部分は実際には対応してる定数テーブルから数字を取ってくる。ofs00nnはジャンプ先の指定で同じ数値入れる。LoaderInfo.parametersから何か取ってきてExternalInterface.callや*.loadに使ってるようなある程度複雑なswfであれば、大体定数テーブルに定義されているので、編集に制限があってもまあ何とかなる。

swfの拡張子を変えてしまう

swfがtext/plainやapplication/octet-streamでホスティングされていれば、swfURLを直接指定されても、Flash Playerを使って表示することがなくなる。objectタグ、embedタグで埋め込む場合には正常に動作して、swfを直接読み込まれた際にはダウンロードになる。

これは異なるContent-Typeでファイルをホスティングするということで、バッドノウハウであるし、将来的にContent-Typeに厳格なれば埋め込み時にも動かないということになるし「むしろ厳格であるべき」だと思っているので、一番簡単ではあるのだけれど、やらないほうが良いと思っている。

クエリとハッシュ強制除去

swf直接表示にクエリストリングが付与されていれば403、では現状効果が無い(その3参照)ので#以降も除去する必要がある。

動的にswfを出力するようにしてトークン付きのURLでなければswfを表示できなくする。#以降にダミーの文字列を追加したURLにリダイレクトすることでlocation.hashも除去できる。

Flash Based XSSについて その3 Flash Player側の問題について

15:53 |  Flash Based XSSについて その3 Flash Player側の問題について - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク -  Flash Based XSSについて その3 Flash Player側の問題について - 金利0無利息キャッシング – キャッシングできます

Flash Player側の問題について考察します

#? 以降の文字列をloaderInfo.parametersで受け取ってしまう件

Flash Based XSSを報告された場合に、とりあえずmod_rewriteでQuery Stringをフィルタして、403あるいはリダイレクトしてしまおう、と(多分多くの人が)考えるのだけど、この修正方法は現時点では使えないものになってしまっている。

Server Filter Bypassの項に書かれている

なんと、FlashのloaderInfo.parametersは、URL中の #? 以降の文字列でもパラメータとして解釈してしまう。

この挙動によって

  • サーバー側のフィルタで回避することができなくなる
  • そもそも#以降がアクセスログに残らないので、悪用されたかどうか自体の判断も出来なくなる。
  • 悪用されている場合には、どんな攻撃コードが実行されたのかの判断ができない。

ちなみにこれはIEswfを直接表示した場合には動作しない。なぜかというとIEが内部的に生成するswfの埋め込みタグでは#以降が渡されないようになっているため。このIEの挙動があるため、#? 以降をloaderInfo.parametersで受け取ってしまうという現状の仕様に依存しているswfは「そうそう存在していない」はずである。この仕様に依存するswfが存在していたとすればそれはIEで動かないswfということになる。

JavaScriptで言うところのlocation.href相当のものをloaderInfo.urlを使って受け取ることもできるし、#以降の文字列を自前でパースすることもできる。なので自分の知る限り、この仕様はServer Filter Bypassの用途でしか使われていない。

そんなわけで去年辺りに「これ仕様だとしても悪用しか使い道ないし、バグとして直した方がいいんじゃねーの」という主旨のことを送って、その時は「XSSが起きるのはswfのバグなんで」的な回答だったのだけど最近また色んな事例と一緒にAdobeの人に再度問い合わせたところ、前向きに修正予定であるという回答をもらった。(ただしいつになるかは分からない) → 修正された http://subtech.g.hatena.ne.jp/mala/20130718/1374146789

ExternalInterface.callでのパラメータ受け渡しがバグってる件

このへんに書かれてる話

ExternalInterfaceを使ってFlashJavaScriptに対してデータを受け渡すときに、Flashは \ をエスケープしない(本来 \ を \\ にすべきところ)。ただし " は \" になる。

そのため \" を含めることで引数として渡される文字列のダブルクオートを閉じることが出来る。例えば「12345\"6789」を渡すと「"12345\\"6789"」となり、途中でダブルクオートが閉じる。この6789の部分にJavaScriptコードを含めることが出来る。異なる言語間でメッセージを受け渡す際に正しくシリアライズしてない、特定の文字列を含めるとぶっ壊れてしまう、のであるから、これは完全にFlashのバグと言える挙動だ。

で、この挙動を迂回するために swfのコード側で \ を \\ に置換するというコードを入れているケースをちょくちょく見る。このswf側での「バグ迂回エスケープ」があるために、単純にFlash Player側でのバグ修正を行うことが出来なくなってしまっている、ように思える。Flash Player側で単純にバグを修正して、互換性にどの程度の影響をおよぼすかどうかというと分からない。何を受渡しているかによるだろう。

自分ならこういう状況に遭遇した場合に「これはFlash Player側のバグなのだからなるべくなら放置したい」「ただ影響が無視できないのであれば当面の対策としてswf側で修正しなくてはいけない」その場合は「Flash Player側のバグが修正されても問題なく動く」ように配慮した修正をしたほうが良いんじゃないか、と考える。バグを修正した後にも動くコードにするには、Flashが \ をどう扱おうと影響を及ぼさないようにすればいい、つまりシリアライズ後の文字列に \ が含まれないようにすればいい。例えばswf側で受け渡すパラメータをJSONにしてbase64エンコードしてJavaScript側でデコードするとか。面倒くさいけど。

バグった仕様を前提にしたコードが生産されてしまうと、バグを修正しづらくなってしまう。とはいっても、Adobeはこの問題の影響を軽減するための対策を取れたはずで、今からでも遅くないのでFlash Player側で何らかの対処をして欲しいところである。

例えば

  • 特定バージョン以下では \ をエスケープするのはswf側の責任として \" が含まれる場合には(引数のシリアライズがぶっ壊れるケースでは)エラーを吐いてExternalInterface.callに失敗するようにする。
  • 特定バージョン以降では \ をエスケープするのはFlash Player側の責任として、swf側では特に何もしなくても良いようにする。

まあこんなふうにすれば、互換性に関わる重要な変更を告知しつつ、古いFlash Playerを使っている場合においても「バグってエラーになることはあっても任意コードが実行されることはない」という修正はできるんじゃないだろうか。

ExternalInterface.callのcallback名は関数名じゃなくても良い

Flashが内部的に生成するJavaScriptコードがこんな具合になっていて

 try { __flash__toXML( %functionName%(%args%) ) ; } catch (e) { "<undefined/>"; }

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/external/ExternalInterface.html#call()

ドキュメント読む限り、functionNameは英数字ってことになってるはずなんだけど、単にfunctionNameに alert(1) とか入れたらそれで通る。

つまりExternalInterface経由で問題が発生するのは

  • Flashとのやり取りにつかっているJavaScriptの関数名をカスタマイズ可能であるか
  • あるいはExternalInterface.callに受け渡す引数に外部からの入力を使っている

ケースで、XSSのための文字列をつっこめるのはcallback関数名でもいいし、引数でも良い。いずれかに自由に外部入力の文字列を設定できてバリデーションしてないのであれば、XSSできる可能性が高いことになる。

Pharmd552Pharmd5522014/11/26 23:44 Hello! dbebkdb interesting dbebkdb site! I'm really like it! Very, very dbebkdb good!

Pharma962Pharma9622014/11/26 23:44Very nice site! <a href="http://ypxaieo.com/rrqsaoo/1.html">cheap viagra</a>

Pharmg417Pharmg4172014/11/26 23:45Very nice site! cheap cialis http://ypxaieo.com/rrqsaoo/4.html

Pharme214Pharme2142014/11/26 23:46Very nice site!

uwubapisuwubapis2019/03/06 12:47[url=http://theprettyguineapig.com/amoxicillin/]Buy Amoxil 500mg[/url] <a href="http://theprettyguineapig.com/amoxicillin/">Amoxicillin 500mg Capsules For Sale</a> http://theprettyguineapig.com/amoxicillin/

ovoboyacufovoboyacuf2019/03/11 12:36[url=http://theprettyguineapig.com/amoxicillin/]Buy Amoxil 500mg[/url] <a href="http://theprettyguineapig.com/amoxicillin/">Amoxicillin Without Prescription</a> http://theprettyguineapig.com/amoxicillin/

uhuyumubuxzauhuyumubuxza2019/03/11 14:49[url=http://theprettyguineapig.com/amoxicillin/]Buy Amoxicillin Online[/url] <a href="http://theprettyguineapig.com/amoxicillin/">Buy Amoxicillin</a> http://theprettyguineapig.com/amoxicillin/

esudropiesudropi2019/03/11 15:00[url=http://theprettyguineapig.com/amoxicillin/]Amoxil[/url] <a href="http://theprettyguineapig.com/amoxicillin/">Amoxicillin No Prescription</a> http://theprettyguineapig.com/amoxicillin/

upalqisoupalqiso2019/03/18 14:05[url=http://theprettyguineapig.com/amoxicillin/]Amoxicillin Online[/url] <a href="http://theprettyguineapig.com/amoxicillin/">Buy Amoxil 500mg</a> http://theprettyguineapig.com/amoxicillin/

pikivixpikivix2019/03/18 20:17[url=http://theprettyguineapig.com/amoxicillin/]Buy Amoxicillin[/url] <a href="http://theprettyguineapig.com/amoxicillin/">Amoxicillin No Prescription</a> http://theprettyguineapig.com/amoxicillin/

ilozademipojilozademipoj2019/03/18 20:54[url=http://theprettyguineapig.com/amoxicillin/]Buy Amoxicillin Online[/url] <a href="http://theprettyguineapig.com/amoxicillin/">Amoxicillin 500mg</a> http://theprettyguineapig.com/amoxicillin/

2013-03-04

カスタムヘッダを使ったCSRF対策は安全に使えるかどうかということについて

19:25 | カスタムヘッダを使ったCSRF対策は安全に使えるかどうかということについて - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - カスタムヘッダを使ったCSRF対策は安全に使えるかどうかということについて - 金利0無利息キャッシング – キャッシングできます

について。

これはsame originからじゃないとカスタムヘッダの付与ができないよ、ということに依存したCSRF対策ということになります。

ブラウザやプラグインの実装がバグってて、色々組み合わせることでクロスドメインでカスタムヘッダの付与が出来てしまうという可能性はあります。最近もそんなのを見かけましたが、POSTかつカスタムヘッダ付与というのは見てないです。POSTで出来たらクリティカルなバグだと見なされるはずです。今すぐ直せって感じになります。

X-Requested-With検証するのと似たような感じですが、X-Requested-Withを検証するというのは、どちらかというとJSON Hijack対策とか、XMLHttpRequestから来るリクエストかどうか保証したいとかで、あんまり通常のフォーム送信の置き換えやCSRF対策といった文脈ではあまり言及されていないように思います。

で、過去にこれ危険なことあるので使っちゃダメ、みたいな感じで言及されていたりします。ただよくよくみると、これはFlashがクロスドメインでカスタムヘッダの付与が出来るので危ないよ、という話なんですね。

参考文献:

上書きできないヘッダ(リファラ等)が上書きできちゃうとマズイし、CORSのヘッダやポリシーファイルが無いのにクロスドメインでカスタムヘッダ付与できちゃうのもマズイよ、というのが現状。

クロスドメインでリクエストを発行できるようなブラウザプラグインは、CORSと同等のポリシーを持つべきです。全てのプラグインがクロスドメインでカスタムヘッダ付加を禁止してくれてるとは限らないので、そういう意味では安心して使えない、ということになりますが、CORSが出来てその辺のポリシーが明確になってるからもう使っていいんじゃねーの、クロスドメインカスタムヘッダ付与が勝手に出来たらプラグイン側のバグだよね、って言える土壌ができている、といえるんじゃないでしょうか。

古いFlashプラグイン使ってたらその時点で、その人は全サイト安全に使うことが出来ないし、俺達はいつまで古いFlashプラグインが使われたいた場合には危険だから、と言い続けなければいけないんだ。古いFlashプラグイン入ってる時点で危険だろ。セッション持ちたくないとかCookie使いたくないようなケースは多くあるでしょうし、まずリファラを見て、リファラが無いのであればJavaScript有効にしてください、といった具合に、あまりユーザーに不便をかけずにCSRF対策が行えるんじゃないでしょうか。

人間が送ることを保証したい(botによる投稿を抑止したい)のであればどっちみちCAPTCHAが必要ですし、犯行予告を送った人間を逮捕していいということを保証したいのであれば、身分証明書をFAXで送らせるとか郵送で仮パスワードを発行するとか、クレジットカード登録させた上でVプリカは弾くとか、Torexitノードは全部ブロックするとか、いずれかあるいは全部を行う必要があります。

JulianJulian2013/09/30 13:06You keep it up now, unnsdetard? Really good to know.

IlyaseIlyase2013/10/01 18:00Your article <a href="http://aejjbdjhr.com">peelrctfy</a> shows what I needed to know, thanks!

AssiaAssia2013/10/01 20:52I'm imsersped. You've really raised the bar with that. http://rxxekzxk.com [url=http://amssyn.com]amssyn[/url] [link=http://utmwizwu.com]utmwizwu[/link]

GalinaGalina2013/10/03 06:12Great common sense here. Wish I'd thhguot of that. http://kunrkl.com [url=http://dfcjldqpy.com]dfcjldqpy[/url] [link=http://eeijrz.com]eeijrz[/link]

トラックバック - http://subtech.g.hatena.ne.jp/mala/20130304

2012-10-25

プライベートブラウズを使用中かどうかを高い精度で判別できるブラウザがあるという話

19:57 | プライベートブラウズを使用中かどうかを高い精度で判別できるブラウザがあるという話  - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - プライベートブラウズを使用中かどうかを高い精度で判別できるブラウザがあるという話  - 金利0無利息キャッシング – キャッシングできます

Safariです。WebKit組み込みブラウザのいくつかも多分そうです。Google Chromeはできません、多分意図的に判別が困難であるようにしています。

  • Safariの場合、プライベートブラウズを有効にするとlocalStorageに書き込めなります
  • Safariの場合、プライベートブラウズを有効にするとDo Not Trackが有効になります

プライベートブラウズ中かどうかを検出する汎用的に使える手法は

  • キャッシュされているかどうかによって、応答時間が変わるケースを利用する
  • ログイン中かどうかによって、ステータスコードや応答時間が変わるサービスを利用する

というものがあるでしょう。例えば多くのユーザーがキャッシュしている可能性が高い画像等の応答速度を調べて全くキャッシュされていないようであれば、それはブラウザのキャッシュを削除した直後であるか、プライベートブラウズ中であると推測できます。多くのユーザーがログインしっぱなしにしているサイトにおいて、ログインしているかどうかを判別する方法があれば、それを複数のサイトに対して検証して、全くログインしているサービスがなければそれはCookieをクリアした直後であるか、プライベートブラウズ中であると推測できます。このように、完璧に防ぐことはそもそも難しいのですが、プライベートブラウズ中であるかどうかを明確に判別できるのは、(自分の知ってる範囲で)Safari(及びいくつかのWebKit組み込みブラウザ)だけで、しかも最近になって「明確に」プライベートブラウズ中であることを条件にして外部から観測可能な挙動を変えるということを仕様として盛りこんできました。

http://www.apple.com/jp/safari/

あなたのプライバシーを重視するSafariは、最新のプライバシー標準である「Do Not Track」に対応しています。「プライバシー」パネルでトラッキングを停止するように設定すると、あなたが訪れたウェブサイトがあなたの行動をオンラインで追跡しないよう、そのウェブサイトに要求を送信します。プライベートブラウズを使っている場合も、ウェブサイトに追跡をしないように要求します。

Safari利用者で、ある程度固定のIPアドレスを使っているユーザーのDNTヘッダの送信状況を調べれば、そのユーザーがプライベートブラウズを利用中かどうかが高い精度で判別できるでしょう。普段はDNTを送信していないのにDNTを送信していたら、それはプライベートブラウズを使っているということです。他の手法でもできるので、多分利用はされないでしょうけれど。

そもそもプライベートブラウジング中かどうかを検出できるとマズイのか?

ということに議論の余地があると思います。例えば、ブラウザベースでのDoS攻撃に加担させられたり、CSRFで犯行予告を書きこまされたりしたときに、PC側に証拠が残らないという問題があります。ディスクキャッシュを使っていて、履歴を復元可能であれば、それはそれでブラウザ側の脆弱性です。ちゃんと証拠が消されなければいけません。

プライベートブラウズ中であれば、殆どのサイトはログアウトした状態でしょうから、Webサイトの脆弱性、XSSCSRFを利用してアカウントの情報を盗み出すという攻撃には遭遇しにくいでしょう。ログイン状態の有無に関わらず成立するような攻撃を受けた場合に、その結果、証拠が自動的に消されることになります。ユーザーは通常、攻撃を受けたことに気付きませんし、プライベートブラウズを終了したタイミングで証拠が全て消えてしまうため、後から検証することもできなくなります。

証拠が残らないなら残らないで無罪で確定ということであれば良いのですが、罠にはめられた人が普段からDoS攻撃を行いそうだったり殺人予告を行いそうな人だった場合、区別が付かなくなるのではないかと思います。

WebKit組み込んでるアプリにおいて純粋にWebKit由来のバグであれば勝手に直ったりするけどWebKitをどういう設定で使っているかに起因する仕様上の欠陥は勝手に直らない

19:02 | WebKit組み込んでるアプリにおいて純粋にWebKit由来のバグであれば勝手に直ったりするけどWebKitをどういう設定で使っているかに起因する仕様上の欠陥は勝手に直らない  - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - WebKit組み込んでるアプリにおいて純粋にWebKit由来のバグであれば勝手に直ったりするけどWebKitをどういう設定で使っているかに起因する仕様上の欠陥は勝手に直らない  - 金利0無利息キャッシング – キャッシングできます

http://subtech.g.hatena.ne.jp/mala/20121023/1351004574 を書いてちょっと嫌な予感がしたので調べてみたのですが

例えばSleipnirの場合

で、ローカルのHTMLファイルからローカルファイルを読み取ってリモートに送るということが出来てしまう。

いずれにせよ、httpからfile://への移動は制限されているので、Webページ閲覧中にいきなりローカルファイルが読み取られたりすることはないです。Appleは問題を認識して、Mountain Lionにおいては、SafariでダウンロードしたファイルをSafariで開く際には安全になるようにしたけど、例えば標準ブラウザをSafariにしていてサブでSleipnirを使っているような人がSleipnirでダウンロードしたHTMLファイルをダブルクリックで開くとSafariではローカルファイル読み放題の状態で開かれてしまう。逆もまたしかり。

問題はいくつかあって、

  • SleipnirにおいてローカルHTMLファイルにおけるSame originが制限されていない
  • Sleipnirにおいてダウンロードしたファイルに拡張属性を付与しない(Lionの場合警告が出ない、Mountain Lionの場合隔離モードで開かない)
  • Safaricom.apple.quarantine を付与しないアプリケーションのことをスルーしている

例としてSleipnirを挙げたけどこれはサードパーティのアプリ全般の問題で、Appleは自社製品を組み合わせて使った場合には影響が軽減するような措置を取ったわけだけど、結局アプリ側が com.apple.quarantine を付けてない場合には、SafariのローカルHTMLファイルの取り扱い自体は変わっていないわけだし、WebKit組み込みのブラウザがどうすべきなのかという指針も示していない。サードパーティのアプリが受信したHTMLファイルにフラグ付けずにSafariで開くような機能付けてたら結局のところそのHTMLファイルからはローカルファイルを読み取ってどっかに送るということは出来てしまう。

ただちに危険だというものではなく、もうユーザーに(ある程度は)そういうものだと認識してもらったほうが良いと思っているので、ブラウザ作ってる人はどういう対応をするかも含めてゆっくり検討すれば良いと思います。

ダウンロードしたファイルにメタデータ付与

Google Chromeと同等のことをやる

setAllowFileAccessFromFileURLs と setAllowUniversalAccessFromFileURLs というオプションがあるので、それを使うと良いです。

これはGoogle Chromeが対応したときに作られたはずです。

Firefoxと同等のポリシーをサポートするかどうかについての議論

そして、ローカルHTMLファイル上でJavaScriptの開発/実行をする場合に、それなりに副作用が大きい変更であるので、Google Chromeはallow-file-access-from-filesという起動オプションで挙動を変えられるようになっている。

アプリケーション実行プラットフォームとしてHTMLを見た場合には「出来て当然、出来なくては困る」のですが、単なるリッチテキストフォーマットとしてHTMLを見た場合には「異常な仕様」で、ブラウザ側が対処しないことにはどうにもならない。いずれにせよローカルHTMLファイルを開くときは気を付けなくてはいけなくて、ユーザーは自分が使っているブラウザのポリシーを把握していなければ安全にローカルHTMLファイルを開けない。この状況は当面改善しないので信用できないHTMLファイルを開くのであればw3mを使うと良い。readme.htmlみたいに単にドキュメントとしてHTMLを配布したい側へのアドバイスは、JavaScriptを含めないことです。特に外部からロードするJavaScriptを含めてしまうと、そのHTMLファイルが安全であったのかどうか後から全く検証ができなくなります。

LarisaLarisa2013/03/06 13:59This is just the perfect awnser for all forum members

glmzvoqetglmzvoqet2013/03/11 01:17k5PiQC , [url=http://wlpafvfxqwnx.com/]wlpafvfxqwnx[/url], [link=http://snzqlhpkhjrp.com/]snzqlhpkhjrp[/link], http://qhucfcvvywmg.com/

トラックバック - http://subtech.g.hatena.ne.jp/mala/20121025

2012-10-23

Safariのfile://におけるSame origin policyについてのアップデート

00:02 | Safariのfile://におけるSame origin policyについてのアップデート - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - Safariのfile://におけるSame origin policyについてのアップデート - 金利0無利息キャッシング – キャッシングできます

http://subtech.g.hatena.ne.jp/mala/20110425/1303730089 を書いた時から、少し変化があったので書いておきます。

SafariにおいてローカルHTMLファイルかローカルファイルを読み取ることが出来るというのは広く知られている問題で、脆弱性として報告されるからには何かしら「攻撃を容易にする方法があった」のだと理解していました。で、表現の問題だと思うのですが、タイトルが"リモートからローカルファイルを読み取り可能な脆弱性"となってて、これだと脅威の度合いを勘違いする人が多いのではという気がします。自分の知る限り、あくまでfile://を何らかの方法でユーザーに手動で開かせる必要があります。

報告者のmasa141421356さんの話を聞いたところダウンロードしたファイルを強制的に開かせる、というものではありませんでしたが、それなりに脅威の度合いが高いなと納得できるものでした。Aaron Sigelという人も報告していて、もっと凶悪な方法があるのかも知れません。が、自分は把握してません。

10/24追記: やっぱWebから直接ではなくて何らかの方法で悪意のあるファイル開かせる必要があるということだと思います

httpから、file:// のURLに遷移したり、iframeで読み込んだりwindow.openで開いたりするのは以前から制限されていて自分の知る限り方法はありません。ただ、いろんな方法で騙して悪意のあるローカルHTMLファイルを手動で開かせようとすることは出来るでしょう。

Safari 6.0.1の場合

https://gist.github.com/3937884

説明するのが既に大分面倒なのですが、簡単に言うと、OSXでは対応しているアプリ経由でインターネットからダウンロードしたファイル全般に com.apple.quarantine という拡張属性が付きます。このフラグがついている場合には、インターネットからダウンロードしたファイルですが開いてよろしいですか、と警告を出したりします。

で、それが

  • LionのSafari6.0.1 → 警告あるけど開いたら何でもオッケー
  • Mountain LionのSafari6.0.1 → フラグ維持したまま安全なモードで開く

という変更がなされました。Mountain LionのSafari6.0.1の隔離モードでHTMLファイルを開いた場合、Same originが自分自身のHTMLファイルに制限されます。これはGoogle ChromeのローカルファイルにおけるSame origin policyと同じです。

Windows版の修正が出るかというと、そもそも開発継続するのかどうかわからないですし、LionとMountain Lionで既に挙動が違っていることから分かるように、対応するとしても結構面倒くさいのではないかと思います。「Lionではファイルを開く際に警告してロック解除」「Mountain Lionではフラグを維持したまま安全なモードでHTMLファイルを開く」と対応が違います。これは、OSがダウンロードしたファイルに対して「一律で警告を出す」のか、それとも「アプリケーション側が面倒を見る」のかという問題です。

信頼出来ない危険なファイル、あるいは、危険なプロトコルに対してOSが一律で警告を出して、アプリ側では配慮しないというポリシーもありでしょうし、Mountain LionSafariのようにフラグを見て、Same origin policyを切り替えるというのもありでしょう。見た目には全然わからないのでややこしいわけですが。Windowsで、これをやろうとするとZoneIdというのがあります。IEと同じことをやらないとダメってことですね。

まとめ

  • Safari 6.0.1にアップデートした場合でも、file://のURLを開く際には一定のリスクがあります。
  • SafariでローカルHTMLファイルを開くのは、条件次第で、依然として危険な状態のママです
  • webarchive形式で保存したWebページは権限が制限されます(安全です)
  • 制限されていない場合、XMLHttpRequesthttp/httpsのページを取得することができます。
  • 制限されていない場合、XMLHttpRequestCookieを送ります。ログイン済みページスクレイピングしたい場合には便利ですし、悪意のあるHTMLファイルを開いた場合には危険です。
  • ダウンロードしたHTMLファイル(com.apple.quarantine付与)は
    • Lionの場合警告が表示されます、警告を無視して開いた場合には無制限です
    • Mountain Lionの場合、Same originが制限された状態で開かれます
  • HTMLをダウンロードしたり生成したりする性質のあるソフトウェア全てが com.apple.quarantine フラグを付けてくれるとは限りません。
  • 例えば wgetコマンドで保存したHTMLファイルにはついてません(まあ当たり前だけど)

Safariでfile://を開くのは、依然としてリスクがある状態であるので、単に「脆弱性が修正された」「Safari6.0.1以降にアップデートを」とアナウンスされてしまうと、かえって危険な状態なのではないかと思います。最新版にアップデートしておけば安心といったものではないですし、ここらへんのポリシーがブラウザ毎にバラバラなのは今に始まったことではないのですし、すぐに解決するような問題ではないです。

以上です。

|