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

複数のニュースサイトで外部サイトにシェアするボタンの実装方法に問題がある件

14:58 |

はてブやらmixiチェックやらgreeいいねやらfacebookのlikeやらのボタンを出力するコードがおかしなことになってる大手サイトが結構ある。

具体的には、こういったコードを使っているサイトが結構ある。

document.write('<a href="http://b.hatena.ne.jp/entry/' + document.URL + '" class="hatena-bookmark-button">はてなブックマーク</a>');

aタグだったりiframeだったり様々だが、共通しているのはdocument.URLやlocation.hrefを「そのまま」出力している点。何がマズイのかというと、document.URLやlocation.hrefにはURLの#以降の部分(location.hash)が含まれていて、URLにダブルクオート(")やシングルクオート(')を含ませることが可能だから(ブラウザによってはURLエンコードされて出来ない)

これによって、aタグやiframeタグを閉じて任意のタグを挿入するということが出来てしまう。この問題を把握したのは今年の2月のことで、悪意のある何者か(自分のことです)によって悪用事例が公開されるなどしているが、一向に修正される気配がないのでブログに書く次第です。

問題があるかどうかの簡単な確認方法

Google ChromeやOperaを使って本来のURLの末尾に

 #"><xmp>'><xmp>

と加えてアクセスしてレンダリングがぶっ壊れないかどうかを調べる。

影響範囲

把握してる限りで大手ニュースサイト3件にこの問題があって、この記事を書いている段階で修正されていない。

• 見かけ上、記事の内容を改変して表示することが出来る。
• そのサイトにログイン機能があるなら、そのサイト上から取得できるログイン済みユーザーの情報が取得できる。

リンクを開く前にURLを確認していれば怪しいと思われることもあるだろうけど、短縮URLだとどこに飛ぶのか分からない、さらに記事の内容を書き換えた上で history.replaceState を使って#以降のゴミを消すというscriptを仕込んでやれば、URLがおかしいという問題点には全く気付かれないだろう(URLにscriptが含まれていたことが分からなくなる)

修正方法

• http://d.hatena.ne.jp/hebita164/20100822/1282491170

こういったものを、そのままdocument.writeやinnerHTMLで出力してはいけない

• location.href
• window.name
• document.URL
• document.referrer

document.URLやlocation.hrefを使わずに、記事がきちんと正規化されたURLを持つようにする

• jsの変数に正規化されたURLをあらかじめ入れておく
• link rel=canonicalを指定した上で例えば jQuery("link[rel=canonical]").attr("href")

補足1

• #以降じゃなくても ?以降の文字列でもURLは自由に変更できる、大抵のサービスは余計なクエリストリングがくっついていてもアクセスできる。
• ?以降の文字列はブラウザによって勝手にURLエンコードされることが多いが、IEではそのまま送られるようだ。
• なので#以降を取り除けばオッケー、みたいな修正方法は間違い。

補足2

一般常識として出力時に適切にエスケープしてやれば、こういった問題は防げるんだけど、その一般常識もきちんとやろうとするとなかなか難しい(から色んなサイトで問題がある)

例えばクエリパラメータで渡す場合は

<a href="bookmark.example.com/?url={$article_url}">

こういった形式の場合は「URLエンコード」%xx%xx%xx 形式に変換するのが正しいだろう。encodeURIComponentで出来る。

例えばPATH_INFOで渡す場合

<a href="bookmark.example.com/entry/{$article_url}">

URLエンコードではなく生のままのURLを期待している、ことが多い。が、しかしhref属性値の中に入れるのでHTMLエスケープしてやらないとXSSが可能になるだろう。

現在見ているURLを単純に出力するようなケースだと

document.write("いま見てるURLは" + location.href + "だよ")

この場合はHTMLエスケープとかHTML Entitie encodeと言われるものが必要、JavaScriptにはデフォルトで無いのでreplaceとか使って適当に作れ。

ブログとかニュースサイトの記事のURLが

 http://news.example.com/artciles/"><script>...</script>.html 

になることなんて通常はありえないよね。だから?以降(クエリストリング)や#以降の文字(location.hash)を含まない正規化されたURLを持っておくようにして、ユーザーからの入力で自由に書き換えられるlocation.hrefやdocument.URLを使うのを避ける、というのも手抜きではない立派な対策方法で、もし変なURLでアクセスされても、URLに対するブックマーク数やフィードバック数を表示するようなプラグインが正しく機能するようになるというメリットもある。

なので状況に応じた適切なエスケープやエンコードについて、きちんと理解してなかったりミスをする恐れがあるなら、記事の正式なURLをあらかじめ埋め込んでおく(link rel=canonicalに入れておけば他の用途にも使えるだろう)、というのが手っ取り早い修正方法だな、と考える。もちろん、URL以外にも、ユーザーが自由に入力することが可能なパラメータが沢山あってそれらを出力する場合は適切にエスケープしてやらないとダメだけど。

直ったら何か書く

• 2011-04-13 21時ぐらい ITmediaとITmedia系列のサイト直った。当日対応。
• 2011-04-14 18時ぐらい asahi.com直った。記事についているfacebookのlikeボタンの出力、アクセス解析用imgタグの出力に問題があった。
• 2011-04-15 読売オンライン ソーシャルボタンとニュースクリップログイン表示箇所に問題があり修正された。

上記に書いた大手ニュースサイトというのは、この三つ。

中の人にフォローされてるので連絡しといた

• 4/15 impressビジネスメディア「Web担当者Forum」「Think IT」の関連記事表示箇所 修正された
• 4/15 nifty デイリーポータルZ ソーシャルボタン表示箇所、修正不完全だったので再度連絡、(多分一時的に)取り外された
• 4/15 gizmodo.jp Facebookシェアボタン 取り外された

gizmodo.jpの件は、Facebookの提供しているJavaScriptライブラリにそもそもバグがあった

• Facebookのセキュリティ担当者をCCに加えてメールした。約24時間で修正された。
• http://twitter.com/bulkneets/status/59120936120623104 http://twitter.com/bulkneets/status/59121415529562112 http://twitter.com/bulkneets/status/59122742955474944
• https://github.com/facebook/connect-js/commits/master
• 特定タグを使用していた場合にFacebook外のサイトでXSSが可能になるという問題であったが、2011-04-18時点で問題の修正はコミットされてないしアナウンスもされていない(githubで公開されてるソースと実際に使われてるソースに差異がある)

たくさんありますね。

把握していて未修正のサイトはまだある。

追記: 2011-04-30

どれぐらい使われているのか全く把握していないが、jQuery.socialbuttonというjQuery pluginに同様の問題があった。

• 配布元 http://itra.jp/jquery_socialbutton_plugin/
• 紹介してる記事 http://phpspot.org/blog/archives/2010/11/twittermixiface.html
• 2011-05-07 PHPSPOT修正された http://phpspot.org/blog/archives/2011/05/jquerysocialbut.html

古いバージョンを使っている場合、外すか、アップデートしないことには直らない。

この手の問題の厄介なのは

• 組み込んでいる対象のドメイン上でXSSが可能になること
• 組み込んでいるサイト側でライブラリをアップデートしないことには問題が修正されないこと
• アップデートを呼びかけないことには修正されないが、同時にどこに問題があったのか(悪用する方法)も公開されてしまうこと

例 → 修正済み

http://phpspot.org/blog/archives/2010/11/twittermixiface.html#"</iframe><script>alert(document.domain)</script>

影響度は、そのドメイン上で任意のJavaScriptが実行できたらどうなるのか、によるので、例えば個人のブログとかだったら実際のところ大きな影響はないだろう。ニュースサイトだったら記事内容を改変されることが深刻な問題であると考えることも出来る(動作ブラウザが限定されるので、本気で嘘ニュースをばら撒く用途には使えないだろう)

そもそも他社ドメインから提供されているJavaScriptのソース(hatena, mixi, twitter, evernoteのサーバーに置いてあるjsのことね)を直接組み込む実装になっているので、本当に重要な個人情報を取り扱っているようなサービスにおいては元々使うべきではない(他社サービスがクラックされたり、ドメイン乗っ取られたり、通信経路で改ざんされていたりした場合に安全かどうかを保証できない)

ライブラリを作る側がバグがないように慎重に設計するのはもちろんだけど、使う側に関しても(特に個人情報を扱っているようなサイトを運営しているケースの場合)使っているライブラリが安全なのかどうか検証することをおすすめする。