2012年3月1日(木曜日)
meta refreshの解釈の差異によって発生する問題
更新: 2012年3月12日15時10分頃
このお話は興味深いですね……「Googleのmetaリダイレクトに存在した問題 (masatokinugawa.l0.cm)」。
meta refreshのcontent属性の中身を動的生成している場合、ここに外部から値を入れられるとき、リダイレクト先を変更できてしまう場合があるという話です。
Internet Explorer 6/7では、以下のようなmetaタグの指定で、http://evil/へリダイレクトします。
<meta http-equiv="refresh" content="0;url='http://good/'url='http://evil/'">
ちなみにHTML5では、ご丁寧にmeta refreshのcontent属性のパース方法が決められていて、「4.2.5.3 Pragma directives - Refresh state (www.w3.org)」に細かく書かれています。
url=の後ろの値の読み取り部分だけを見ると、以下のような感じになります。
- 17. 空白をスキップ
- 18. 単引用符もしくは二重引用符があれば、変数quoteにその文字をセット
- 19. content属性値の最後まで文字列を読み取る
- 20. quoteの値に何かセットされていて、それと同じ文字が文字列に含まれていれば、それ以降の文字をすべて切り落とす
- 21. URLの末尾からスペースを切り落とす
- 22. URLの中からタブ、LF,CRを削除する
20. の処理でquote文字列の後ろはすべて切り落とされることになっているので、問題のケースでは http://good/ がURLとみなされるのが正しいです。IE6/7の処理はHTML5の仕様とは異なっています。
とはいえ、そういう残念な処理をするブラウザが存在するというのは事実なので、注意が必要になるということですね。
以下も似たような話です。
- IE6/7の<meta refresh>では「;」で区切ってURLが複数指定できる問題 (d.hatena.ne.jp)
こちらも、IE6/7の解釈がHTML5仕様と異なっているという問題です。HTML5の仕様上は、;url= は単にURLの一部とみなされるのですが、IE6/7はそうは解釈しないということですね。
ちなみに、content属性の値はまずHTMLの属性として解釈されるので、数値文字参照や名前つき文字参照は、url=を解釈する前の時点で展開されています。つまり、URL中の単引用符を ' や ' と書いてエスケープしようと思っても無駄です。
%27にエスケープするなら意味がありますが、URIの意味が変わってくる場合があります。' はRFC3986で sub-delims に含まれている文字なので、生でURIの中に出現することがあり得ます。
※2012-03-12追記: 上記部分部分、生「'」は普通出現しないと書いていましたが、ご指摘を受けて訂正しました。ありがとうございます。
そんなわけで、レガシーなブラウザを考慮するとmeta refreshの動的生成は注意が必要、という話ではあります。
※しかし、そもそもmeta refreshなどというものを使う必要があるのでしょうか。時間指定のリダイレクトにはアクセシビリティ上の問題がありますし、「ページの自動読み込み」を無効にしたIEなどではmeta refreshは全く機能しないわけですから、必ず代替手段を用意しておく必要がありますし。
- 「meta refreshの解釈の差異によって発生する問題」にコメントを書く
関連する話題: セキュリティ / プログラミング / HTML / Internet Explorer
Windows Azure, 閏年問題でダウン
更新: 2012年3月15日14時0分頃
こんなニュースが……「Microsoftの「Windows Azure」、閏年関連バグでダウン (www.itmedia.co.jp)」。
実はうちの会社でもWindows Azureを使った案件をいくつか持っていて、思いっきり影響を受けました。日本時間の朝10時頃からサービスがダウンし、管理画面からの再起動も受け付けない状態に。しかも、社内で最も詳しい人は「2012 MVP Global Summit (www.2012mvpsummit.com)」に呼ばれていて、日本にいないという厳しい事態。
幸いメールで連絡がついて、しかもすぐそばにAzureのMVPの方がいたらしく、むしろ通常よりも強力なサポートが得られる結果になりました……が、結論としては「Azure全体の障害なのでどうしようもない」という話で、座して待つ形に。
※日本時間で夜の21時頃には復旧していたようです。
……というようなことが起きたのですが、それがまさかの閏年問題だったようで。正式な障害報告書はまだ見ていませんが、Microsoftの方からの簡単な報告によると、証明書関係の処理で問題が起き、障害の範囲拡大を防ぐためにサービスを停止したということらしいです。
証明書の有効期限チェックの処理で閏年問題が発生したのだとすると、それはまあ動かなくなるでしょう。Azureの内部ではいろいろなところで証明書を使っているようですし、証明書のチェックは一見するとカレンダーとは関係なさそうに見えるところで、盲点になっていたのかもしれません。
Azureに限らず、証明書や鍵の有効期限をチェックするシチュエーションは増えていると思います。そこで問題が出ると影響が大きいので、注意する必要がありそうですね。
※2012-03-15追記: 有効期限のチェックで問題が起きたのではなく、証明書の新規作成に失敗したということのようです……「Azure閏年問題の詳細」。
- 前(古い): 2012年2月29日(Wednesday)のえび日記
- 次(新しい): 2012年3月2日(Friday)のえび日記
