ホストの前に文字が置けることを忘れるな

今日は、 そもそもホストの前に任意の文字列を置けるということを忘れていると、うっかりそこにJavaScriptで触ってしまった時に問題が起こる場合があるよね、という話をします。
以前紹介したlocation.hrefの問題に似ていますが、今回取り上げているのは文字列がデコードされることにより起きうる問題ではなく、文字列が取得されることで起きうる問題についてです。
 
まずは、様々な形でJavaScriptでURLを確認できるスーパーウェブサイトを用意致しましたので、ホストの前に文字列を含むURLが、どの値で取得されているかを実際に見てみてください。

http://user:pass@vulnerabledoma.in/location/

(※このページはURLをそのまま書きだしているため、当然DOM based XSSがありますが 、その挙動も含めて確認できるようにする目的があるので、あえてそうしています。良い子はこのようなコードを書くべきではありません。)


いろいろなブラウザでアクセスすると、様々な違いがあることがわかると思います。

まず、アクセスするところから違いがあります。
Chrome/Operaは何事もなくアクセスします。Firefoxは認証情報をもってアクセスする旨のプロンプトが出ます。Safariはデフォルトの設定でフィッシング警告が出ます。IEはそもそもアクセスできません(ので、今回は、珍しくIEの出番が早くもここで終了です!!!!!)。

取得された@の前の値を見ていきます。
Firefoxはlocation.*以外のURL全体を取得するような値で、user:passが取得できています。
Chromeは、全てのURL全体を取得するような値で、@の前の文字列を全て取得できています。
SafariもChromeと同様、全てのURL全体を取得するような値で@の前の文字列を取得していますが、値によってパスワード部分を含んだり、含まなかったりしています。
Operaはdocument.URLのみ@の前の文字列を含んでいますが、パスワードの部分はマスクされて取得されています。

見事にバラバラですね。他の値についても結構バラバラで、注意すべき点があるので、今回はその点には触れませんが、興味がある人は見てみてください。

さて、いろいろ見てきましたが、いちいちこのブラウザのこの値では@の前の文字列がデコード/エンコードされてこの部分が取得されて～～って覚えましょうと提案している訳ではありません。
今回覚えておいてほしいのは、ホストの前に文字を置くことができ、それはJavaScriptで取得されるということです。特に、使用頻度が高い「location.href」で、Chrome/Safariにおいて、@の前の文字列が取得される点は注意が必要だと思います。忘れるとこういうことになるかもしれません：

ここでアラートを出しているのは、Googleが404ページにどうぞと提供しているJavaScriptに存在していたXSSによるものです。このJavaScriptファイルを読み込んでいただけで、設置サイトのドメイン上で動作するXSSの穴をあけてしまっていました。どこに問題があったかは、この画像のフレームが挿入されている部分と、このjsを設置した以下のサイトを見比べればわかると思います。

 http://vulnerabledoma.in/wm404.html

フレームが挿入されているところに「vulnerabledoma.in のページを検索:」と、ホストを書きだしている部分があります。そうです、このホストを書きだす部分の処理で、ホストの前に@で文字列が置けることを意識していなかったため、@の前までもがホストとして書き出され、XSSが起きてしまったという訳です。強調しておきますが、スクリーンショットのXSSがChromeで動いているように、これはSafariのlocation.hrefがデコードされる問題とは関係なく起きた問題です。

という訳で、ホストの前に文字を置くことができ、それはJavaScriptで取得されるということを忘れないで、location.hrefのようなURL全体を取得する値を使うようにしましょう、というお話でした。以前location.hrefのブログを記事にした時に、@uu59さんが指摘されていたこんなのもあり得そうなミスですね。

ちなみに、このGoogleの提供する404ページのJavaScriptの問題は、2012年3月12日に報告し、しばらくして修正されました。この報告の報酬として$1,337をもらっています。