■

■ブラウジングと電子メールの安全性を強化する：ハッカーや攻撃者から身を守ることができる４つのステップ

ハッカーという単語の使い方が間違っているような。そろそろクラッカーという単語を世間一般でも定着させたらどうでしょう。それはともかくとして。

ブラウジングと電子メールの安全性を強化する：ハッカーや攻撃者から身を守ることができる３つのステップというページがマイクロソフトの日本語サイトにあります。日本語版では３つのステップです。2003年12月16日公開で最終更新日も2003年12月16日ですね。

一方、これに相当する本家の記事は、Increase Your Browsing and E-Mail Safety: 4 Steps to Help Ward Off Hackers and Attackersです。こちらでは4 Stepsですね。Updated: June 11, 2004ですので最近になってひとつステップが増えているということでしょう。

何が増えているかと言うと、Step 4: Block Pop-Up Windows in Your Browserというステップが追加になっていますね。ポップアップブロッカーを使いましょうと。MSNツールバー(日本語版)のポップアップ禁止機能を推奨しているようです。

セキュリティー強度は確かに高まるはずですし、IEを使う使わないはともかく広告ウザイという人など、ポップアップブロッカーを使っている人は多いのではないでしょうか。単体でも色々な種類がありますし、何かのソフトの付属機能であったりもするようです。

さて、あなたのポップアップブロッカーはいったいどれほど優秀なのでしょうか。実は品質にはかなり差があるようなのです。ポップアップの方法は非常に多くの種類があるのです。あなたのポップアップブロッカーがどれだけカバーできているかは、ひとつ試しておく必要があるかもしれません。そんな時に便利なテスト用サイトをご紹介しておきます。

PopupTest - test your popup blocker software and download software
http://www.popuptest.com/

ソースを見てたまげるほど、これでもかこれでもかとポップアップのバリエーションがあるのですね。その上、興味深いことに、「むしろブロックしてはいけないポップアップ」についても論考されています。しかし、ユーザビリティー的にどうよ？という疑問符を私はつけておきます。javscriptオフの人のことを考慮していないならダメダメですので。さて本題に戻ります。たとえばですね、Opera7.51のポップアップ防止機能を試してみるとか、googleツールバーではどうだろうか、とか、面白いですよ。アンチウイルス製品にもポップアップブロック機能はあるのかな？これも調べておけばいいでしょう。企業ユースで推奨できるブロッカーを探すのも面白いかもしれませんね。

■もうだめぽなIEのURLアドレスバー偽装

論評抜き。もうだめぽ。

６年も前の呪(シュ)が復活していたのを見てガッカリというそれだけです。

http://www.malware.com/targutted.html

http://secunia.com/advisories/11966/

気をとりなおして追記。今のところ適切なポップアップブロックが可能ならば上の例のURLアドレスバーの偽装は防止可能である確率が高いと思われます。まだ不明な点がありますがこの際ですからウッカリ踏んでしまったりすることにそなえてポップアップのブロックを検討してみてはいかがでしょうか。ポップアップは脆弱性を自動的に踏ませる為に使われます。ポップアップ以外にも脆弱性発現を仕掛ける方法がみつかるかもしれませんが。。。あるなぁ、、きっと。脆弱性そのものはjavascriptを必要としませんが、見破られ難い優秀な罠として機能させる時にjavascriptが有効。という具合です。また、想像に過ぎませんがもしかしたらiframe要素での可能性も調べておくべきでしょうか。

Secuniaさんによれば、同問題が発見されているのはIEばかりではないとのこと。以下一覧。

上にあげたもの以外も可能性があるとのこと。要注意です。下記のURLにて脆弱性があるかどうかの自己診断が可能ですので御試しください。Firefox 0.9.1では安全とのウワサですが私はまだ試していません。

http://secunia.com/multiple_browsers_frame_injection_vulnerability_test/

そろそろ良い機会ですからサイト運営者さんもフレームなんてやめましょう。セキュリティー上以外でも問題がありますからね。事実、あたまのいいところではフレームによるナビゲーションなんてやめちまってますよ。フレーム、あんなにはやりましたけれどね。

■モーダルが当然のalert()について何かしらモーダルではないときがあります。

バグではありますが、表題の意味においてセキュリティー上のリスクとは直接結びつきませんし。うーん。

当日記では結論が出ないまま書きかけの文書をあげたまま放置する傾向があります。何故なのかはひたすら私の無能に起因するのですけれども。ちょっと書いてみますか。

モーダル(modal)であるということ

WindowsのIEではモーダル(modal)という言葉を技術的な意味で使うことがあります。モーダルとは、私の感覚では、決定されるべき在り方、あるいは、他に優先的な在り方、というニュアンスなのですが、正確にはわかりません。モードという言葉とも関係があるでしょう。「今年の最新のパリのモードでは水着は泳ぐ美を強調したものであり躍動感を表現したものであり肌の小麦色と似合う洗練された生命を謳歌するものだ。」という例文を考えてみました。この場合、泳ぐ美を優先あるいは決まり事あるいは真っ先に選択する勢いとして捉えることがモーダルなのではないでしょうか。私の感覚では心許ないので、英辞郎で調べると以下のような説明があります。

  • 【形-1】 叙法の、旋法の、様式の、様態の
  • 【形-2】 《コ》（ダイアログ・ボックスが）モーダルな◆ユーザが応答しない限り、そのプログラムの他のコントロールは入力を受け付けない。別のプログラムには切替可能

それではWindowsのIEにおけるモーダルって何？とも思いますので、ごく簡単なモーダルの例を次に考えて見ます。

警告ダイアログ(alert)はモーダルである

次のようなソースのHTMLファイルを作成してみて下さい。a.htmlとでも名前をつけてデスクトップに保存し開いてください。ごく簡単なものです。

<html>
<script>
alert();
</script>
</head>
<body>
<p>hoge</p>
</body>
</html>

このa.htmlは上のソースを見ておわかりの通り、「hoge」という文を書いたものです。従いまして、このHTMLを開いたときに、もしもあなたのIEがjavascriptを作動しないように設定していれば、あなたは「hoge」という文字を見るかもしれません。さて、多くのユーザはjavascriptを作動するようにしています。そして、その場合、このHTMLファイルを開いたときに、そのユーザは、最初、「hoge」という文字を見ることはありません。ユーザが見るのは、javascriptが表示する、空のalertであるはずです。このalertが表示されている限り、IEは「hoge」を表示しません。

警告ダイアログ(alert)はモーダルなのです。それゆえ、ユーザがなんらかの応答処置をすることが最優先なのですね。応答をしない限り、a.htmlは何も出来ません、っていうか何もさせてもらえません。従って、最初、「hoge」なる文字は表示不可なのです。ユーザがこのalertに応答を返した後に、はじめてa.htmlは息をふきかえし、レンダリングを再開し、「hoge」なる文字を表示します。以上の説明にて、警告ダイアログ(alert)がモーダルであることの簡単な説明をしました。

モーダルなんだからあたりまえ

続いて次のようなHTMLファイルを作成しましょう。a.htmlとほぼ同じですが、b.htmlと名前を付けておきます。b.htmlはa.htmlに一行追加したものなのです。

<html>
<script>
alert();
location.href="http://www.microsoft.com/";
</script>
</head>
<body>
<p>hoge</p>
</body>
</html>

このb.htmlで追加された一行は、location.hrefにて、www.microsoft.comへの参照を指示したjavascriptのステップです。b.htmlにて期待される挙動は次のようなものであると考えられないでしょうか。私の感覚ではそうなのですが。人によっては異なるかもしれないですね。最初に、モーダルな優先権を有するalertが表示されます。この時点では、「hoge」は表示されません。alertにユーザが応答すると、IEは次の動作に移ります。「hoge」を表示するべきです。そして、javascriptのalertの次のステップ、location.hrefにて、www.microsoft.comへの参照を行うべきでしょう。モーダルな権利を有するのはalertだけですので。モーダルな権利を有さない「hoge」の表示と「www.microsoft.comの参照」とは、もしも競合するのならばHTML記述が優先されるべきです。残念ながら、いくら目を大きく見開いていても、このb.htmlを開くとユーザは次のようなことがわかるはずです。すなわち、最初にalertが表示されて、モーダルである。従って、「hoge」は表示されない。alertに応答を返すと、IE「hoge」の表示は放棄し、直ちにwww.microsoft.comの参照を行う。

非常に感覚的なお話しで恐縮です。恐らく、多くの人が、IEのこの挙動を自然な振るまいであると感じるであろうことは予想がついています。しかし、モーダルなのは、alertだけなのではないのか？という疑問があります。どうして、location.hrefのプロパティー変更が先走りますか？なんでまぁ、たかがスクリプトのくせにマークアップよりも優先権が与えられていますか？と私は憤慨するのですが、まぁ、わかって頂ける自信がありません。青年の主張？はさておき、次のc.htmlをIEにてご覧頂きましょう。

モーダルな手順前後に輪を掛ける

c.htmlを次のように作成し、開いた時の挙動を観察しましょう。環境によっては私の意図する挙動は示さない可能性が若干あるのですが、そうであったらごめんなさい。

<html>
<script>
location.href="http://www.microsoft.com/";
alert();
</script>
</head>
<body>
<p>hoge</p>
</body>
</html>

このc.htmlとさきほどのb.htmlとの違いはほんの少しです。alertとlocation.hrefの順番を入れ替えただけです。私のまっとうな？感覚では、少なくとも、location.hrefによる参照が処理されたならば、その後の一切のjavascriptのステップは放棄されるべきです。だって、webページが切り替わるのでしょう？切り替わった後でどうして、切り替わる前のページのjavascriptのステップが作動していいはずがありましょうか。

c.htmlを開いて発見する驚くべきこと、実際には、alertは実行されるのです！そして、このalertはそれ自身モーダルであるべき、すなわち、alert以外は一切一時停止！であるべきなのですが、おかしなことにalertの呼び出し元のc.htmlを眠らせません。おっと、alertに手をつけないで下さい。そのまま我慢します。そして観察してください。c.htmlのレンダリングはちゃくちゃくと進み、おそるべきことに、遷移先である、location.hrefで宣言された、www.microsfot.comのコンテンツが表示されます。（私同様に運がよければ）このwww.microsoft.comのコンテンツ表示は１０秒もあれば完了することでしょう。表示が完了した時点で、驚愕すべきは、、、、アドレスバーの表記は、、あなたが作成したc.htmlの保存先のままなのです。www.microsoft.comではありません。alertに応答してみましょう。アドレスバーの表示は、www.microsoft.comに切り替わらないことでしょう。c.htmlの保存先のままなのです。運がよければ。。。。（私のマシンでは、このHTMLとjavascriptの競合が非常にうまく行きまして良い按配なのです。100発100中です。)HTMLとjavascriptのタイミング競合(レースコンディション)は微妙ですので、もしも私の今書いている事があなたのマシンで再現できなければ本当に申し訳ないことです。ごめんなさい。何人かの人が有するマシンではこのことが再現できすようです。一方、何人かは、全く再現できていません。この理由は今のところ私にはわかりません。再現可能なマシンとそうでないマシンとどちらが多数派なのかもわかりません。ひとつだけ忠告しておきますが、私は例題で、microsoft.comをひきあいに出しました。お願いですから、任意のサイトで実験しないでください。今のところ、この現象が出るサイトは他に、（あたりさわりのない範囲で言いますが）www.google.comぐらいなものでしょう。ある種の感触があるのですが、確証がとれませんので、どういうサイトがこの変な現象をおこすのかについては今回は明言出来ません。IEが利用するキャッシュの取り扱い方法に関してHTTPレスポンスで何かしら既定があり、その関連で発生しているに違いないのですが。。。

ここまで書いた事ってセキュリティー上で問題があることなのでしょうか。結果論ですが、c.htmlのアドレスで、コンテンツの中身がwww.microsoftである、これは本当に不思議な現象ですし、ある意味とっても不具合なのですが、直接的な悪用は極めて困難でしょう。フィッシング詐欺では、悪意ある者は、正当な（あるいはそれにみせかけた）アドレスに対して悪意ある詐欺的なコンテンツを組み合わせることに意味を得るのでしょう。今書いているこの記事では全く逆です。ニセモノのアドレスで正当なコンテンツを表示して何か悪用できますでしょうか？

もうひとつのモーダルは危険なのか？

javascriptのモーダルなalertでは危険性が無いと確信しております。しかし、もうひとつ、モーダルな権限を有する不思議なオブジェクト（ないしメソッド）がIEでは用意されています。それは、「showModalDialog」です。

ModalDialog自身は、単なるalertとは異なり、スクリプトを含むHTMLファイルでもって（alertな）Dialogの替わりにできるものであり、しかも、呼び出し元に対してモーダルです。

ModalDialogに呼び出し元のwindowオブジェクト自身を引渡し、返り値として（何もしませんが）そっくりそのままwindowオブジェクトを返させることが可能です。ModalDialog自身は何もする必要がありません。呼び元からwindowオブジェクトをもらって返す、それだけです。タイミング的にはレイスコンディションの問題がありますが、まぁ適当に。一番簡単なのは、ユーザに充分な時間がたってからModalDialogをクローズしてもらうことです。これでＯＫ。ここまで論じたalertの替わりに使っってもよいのです。

モーダルなalertの実験同様なのですが、呼び出し元のコンテンツ内容がlocationか何かで本来のアドレスのコンテンツからずれまくりをした後に、ModalDialogが返してくれるオブジェクト（=元のwindowsオブジェクト）のhrefプロパティーの変更をかけてしまえたらとんでもないこと、、なのです。タイミングが競合しているのですね。で、ある種の環境ではそれが出来てしまう。modalなHTMLが返すwindowオブジェクトを起点に遷移前のページに書いてあるスクリプトが遷移先のページのDOMを改変操作できてしまう、あるいは読み取ることが可能だ、という事実にぶちあたるワケです。早い話がXSSです。

このことを発見し問題にした人は、中国のセキュリティー問題研究家であるliu die yu です。Bugtraq: IE/0DAY Insider Prototype というPOSTでこのことが示されました。20040621のことです。この問題は、日本でも各種のメディアで報道ないし記述されている、既にスパマーが応用していることを発見したjelmerによる研究になる「http://secunia.com/advisories/11793/」から派生したものです。dieとjelmerとの方向性は異なるのですが、モーダルなHTMLって権限が強すぎないか？タイミングはどうよ？という意味で同根です。

あるスパマーはこのことをセキュリティー関連のMLや各種のアドバイザリーとは独立にみつけていました。実際にそれらは応用されていたのです。明らかになってよかった事例のひとつでしょう。

追伸：dieによるXSSは任意のサイトに応用できるものではありません。キャッシュコントロールをある種の設定にてサーバ側にて行っている事、そして、ブラウザ側でその設定にみあった応答をすること、という条件がつきます。そして、この条件は、天才であるdieにもわかっていません。。。。dieがあなたに示すことが出来ることのひとつは、www.google.comが発行するcookieをあなたから盗み出すことが出来るということだけです。