認証情報付きアドレスに対するブラウザの挙動の比較 (location.href の話)
先日、夏のちょっと怖い話としてlocation.hrefの盲点という文章が公開されました。
デスクトップでこの影響を受けるのは Safari5 (Windows または Snow Leopard 以前の Mac) くらいのもので、対象者は少ないんじゃないのかなーと予想しますが、
残念なお知らせがあります。Safari Mobile/Androidの標準ブラウザもこの動きをするのです。
さらに、Androidの標準ブラウザは@付きURLにアクセスする時に警告も出しません。今この情報を出した一番の理由として、このモバイルの問題をどうやっても早急に解決できないことがあげられます。モバイル端末のアップデートは機種によりまちまちで、提供されるかもわかりません。そんな現状で、このような潜在的な問題が早く修正されるとは思えません。アプリケーション開発者で対応するしかないでしょう。
http://masatokinugawa.l0.cm/2012/08/safari-location.href.html
とのことなので、モバイル利用者の方々には Opera Mobile などの、Mobile Safari を使用していないブラウザをお勧めする*1とともに、開発者の方々には影響の調査と修正をお願いしたいところです。
たいていは同じオリジンのリソースの読み込みにはホスト名以降の相対パス(../js/hoge.js とか /static/hoge.js とか)が使われるかと思いますけれども、location.href からアドレスを組み立てるなどしている箇所があれば、そこに今回の問題があるかもしれません。
以前であれば外部リソースを読めるのは SCRIPT 要素を使った js (JSONP) 位のものでしたが、XHR level2 によってサーバーが許可していれば XHR でも読み込めるようになりました。「XHR で読み込めたんだから同じオリジンのはず」という状況ではなくなっていますので、SCRIPT にしろ XHR にしろ、外部リソースを読み込む場合はそのサーバーがリクエスト時に意図したサーバーなのか、というのは注意が必要でしょう。
（詳しくは jQuery MobileのXSSについての解説 - 金利0無利息キャッシング – キャッシングできます - subtech 等）
さて、本稿では今回問題になった「認証情報付きアドレス」を各ブラウザがどのように扱っているのかというのを比較してみます。
テストページとして http://jsrun.it/miya2000/2Lyx を用意しました。jsdo.it を使用させていただいています。
[ユーザー名] と [パスワード] を入力して実行すると、http://[ユーザー名]:[パスワード]@jsrun.it/miya2000/2Lyx?dummy というアドレスを生成して iframe に設定し、その location.href を確認します。ついでに a 要素の href プロパティについても確認しています。
私のほうで確認できる環境のテスト結果は上記のテストページに貼り付けました。各ブラウザで違いがあって面白いですね。
以降はテスト結果に対するまとめになります。
「認証情報付きアドレス」についておさらい
(後で書く)
(もう書かない)
