■
■そのサイトは本物? 偽アドレスバーを使った新手のPhishing詐欺
“phishing”の新たな手口が出現，「今まで見たことがない」――業界団体 : IT Pro ニュースから以下、引用します。
新たな手口では，ブラウザに表示されるアドレス・バーをJavaScriptとフレームを使って偽装する。「今までに見たことがない手法だ。」
罠のページに行くと、新しいウインドウが開くが本来のアドレスバーは見えなくされており、かつ偽者のアドレスバーが出現、そこには銀行のアドレスなどが表示されている、これは悪意ある偽のアドレスなので、普段からURLアドレスを確認する賢明なユーザであっても偽のオンライン口座取引などをしてしまうといったフィッシング詐欺にひっかかりやすい、ということでしょうか。
おそるべきことにその偽のアドレスバーに別のURLアドレスを入力するときちんと動作するので、事後に罠にかかっていたことに気がつきにくいというオマケつきなのですね。
さて、この手口、技術的にはそれほど難しいものではないかも知れません。
ちょいと見てみましょうか。下記にとあるマイナーなコンピュータセキュリティーサイトのフリーなwebプロキシページを紹介いたします。あ、ちょっと待ってください。訪問前に心の準備の為、いくつか説明をしておきます。紹介するページのプロキシではWindowsIEの為にセキュリティー的に見て有害なコンテンツの部品があるかどうかを調べつつプロキシするという按配です。（精度はともかく。）WindowsIEでない人にはつまらないものだと思います。と言いますか行っても無駄です。
訪問すると、プロキシを通して見たいサイトのURLアドレスを入力する欄があります。プロキシは日本語に対応していませんので、適当に英語のページ、できれば静的コンテンツがおいてあるページのURLアドレスを入力してください。自動的にリダイレクトするようなものは駄目です。ちょっと時間がかかるかなぁと思いますが（２０秒ぐらいか）表示された画面を見てください。そして、新たにプロクシを通して見たいURLアドレスを投入して見てください。
表示される画面はフレームを使っています。また、プロキシを希望するURLアドレスの入力欄はアドレスバーに似せてあるものの、あえて区別が微妙につくようにしてあります。もしも本物のアドレスバーが見えなくなっていたとしたらどうでしょう？
私は技術には詳しくありませんし非専門家ですが、このようなものは容易にブラッシュアップ出来るのだろうなぁとの感想を持ちました。
The Security Authority - Tools - Web がご紹介するプロキシです。
負荷に対してヨワヨワなので皆が見ていなさそうな時間帯を狙って見てください。
■iframeの無限ループでIEがメモリを食い尽くすお話し
http://archives.neohapsis.com/archives/bugtraq/2004-04/0080.htmlに記事、『Internet Explorer 6 - Crash』というのがあることを、ネットワーク・セキュリティ・ニュース４月８日の記事経由で知りました。http://archives.neohapsis.com/archives/bugtraq/2004-04/0080.htmlでは、単純に以下の事実だけが書いてありました。すなわち、<iframe src="?">とHTMLに書いて開くとIE6がクラッシュすると言うのですね。
ちょっと変形して以下のようなソースを用意して開いて見ると原因がわかります。
<div>aaa</div>
<iframe src="?">
無限に内側へと開きつづけるiframeには、上記の例では『aaa』という表示が見えるはずです。つまり、このHTMLは自分自身を自らの内側にiframeで貼り付けているわけです。貼り付けられた自分もまた自分自身を内部に抱えますので、かくして無限に貼りつづける事に。。。というわけで処理が終わらずにクラッシュするわけですね。
通常ですと、この種の無限ループは検出されて防止機能が働くように設計されていなければなりません。本当にそうなっているのかをチェック出来ます。インターネット上のURLアドレスを適宜決めて、そこにHTMLを作りましょう。置き場所に、そうですね、test.htmlという名前で保存することとします。HTMLの内容は以下の通りとします。
<iframe src="[置き場所の絶対パス/test.html]">
自分自身を呼び出してiframe内に貼りつけるわけです。はたしてこれを開くといったいどうなることでしょうか？実際に行って見ると、IE6では、無限ループになりません。無限になりそうなことをシッカリと検出して防止機能が働きます。安全設計。
同様に、a.htmlがiframeでb.htmlを貼りつけ、b.htmlがiframeでa.htmlを貼りつけているとしましょう。ちょっと考えるとすぐにこれもまた無限ループを構成していることが判ります。そして実験してみるとやはり無限ループにはなりません。安全設計。
さて、以下のようなHTMLをローカルに作って開くとより一層今回の問題がわかります。「?」の正体が。パスの中で?の左側に自分自身を補填した上、iframeで内部展開したときに、こともあろうに「?p1=111&p2=222"」と「置き場所の絶対パス/test.html?p1=111&p2=222"」とが一致していないので無限ループになっていないと判定しているのでしょうね、きっと。
<iframe src="?p1=111&p2=222">
■iframeの無限ループでIEがメモリを食い尽くすお話し（4/11追記）
iframe要素のobject要素による差し替え(WinIE)
上はどうも舌足らずのような気がしましたが、さらに舌足らずな追記を、WinIE用に。
HTML4からはobject要素がiframe要素やapplet要素やimg要素をも包含する要素として登場しているかと思います。この流れを見ていくとXHTML1.1ではiframe要素やapplet要素は廃止になっている模様です。また、HTML4ではobject要素はiframe要素の代行が可能であると考えても良いでしょう。（但し、一部のブラウザでは対応が不完全です。）このことを踏まえて、iframeの無限ループとobjectの無限ループとを対比しておこうと思います。
object要素でHTMLを埋めこむ（貼り付ける）
iframe要素でHTML内で(他の)HTMLを埋めこむことはよくみかけます。（余談ですが、最近著作権がらみでiframe要素はリンクなのかという討論がweb上でありましたが私はiframe要素を『いわゆる社会的通念上の』参照型リンクとは考えません。iframe要素はobject要素やimg要素と同じ位置付け、すなわち埋めこみタイプであろうと思ったからです。著作権を主張する他人様のオブジェクトを勝手に自分のHTMLに埋めこんではいけません。一方、参照型リンクはお互いにどんどんすべし。ほとんど自明ですよねぇ。)object要素によるHTMLの埋めこみは実際には下記のような記述が可能でしょう。
<object data="a.html" type="text/html" width="320" height="160">
alternated contents
</object>
セキュリティー上若干iframe型とは扱いが違いますが（悩ましいことに違う意味がわかりませんが）上の例ではiframeと同じことがobjectで出来できしまう例となっています。
フラグメントではiframeで無限ループしない
『フラグメントではiframeで無限ループしない』、わけのわからない見出しなので以下に例を。
<iframe href="#">
</iframe>
先に 述べた『?』では無限ループしたのに、フラグメントを記述する『#』では無限ループしないのですね。同じURLの仲間ですのに何故でしょう。
『?』でobjectは無限ループするか
以下の実験で、『?』でobjectは無限ループするかを確認できます。
<object data="?" type="text/html" width="320" height="160">
alternated contents
</object>
予想通りですが、iframe同様、objectでもやはり『?』で無限ループします。
『#』でobjectは無限ループするか
iframeでは無限ループしなかった『#』ですがobjectではどうでしょう。下記のような実験をしてみます。
<object data="#" type="text/html" width="320" height="160">
alternated contents
</object>
iframeでは無限ループしなかったのにobjectではしてしまいます。これは意外でした。思うに、iframeで『#』による無限ループは比較的早くに露呈していてサッサと修正していたのではないかと。フラグメントが同一文書内を指すことは自明ですから開発途上ですぐさまテスト項目にあがったと思われます。一方、『?』なんてCGIでもなければつける機会がありませんから失念したのかもしれません。一方、objectではテスト項目がいっぱいあって手がまわらなったのかなぁと。objectでHTMLを埋めこむことは仕様上には存在しても実用上想像していなかったと。いや、邪推ですね。すみません。
iframeはobjectで代替可能だからセキュリティー上では？
追記の本論と言いますか結論なのですが、iframeで何かあったらobjectでも当然検査しなくてはいけないのだなぁと痛感しました。
ひとりごと
ところで最近、私はiframe周辺で何かの対策の為にユーザスタイルシートをいじってませんでしたっけ？そうでした。実は深いところで私の中ではつながっている話題なのですね。一連の思考のなかの断片をはてな日記で浮上させてみました。
なにかの対策ユーザスタイルシートは現在も検討中です。本日は主にサーバサイドクリッカブルマップ（イメージマップ）周辺で何か偽装できるのか、そしてその対策は？と考えておりました。近いうちに結論を出したいと思っています。また、Kamadaさん発見のクライアントサイドイメージマップによる偽装をスタイルシート主導でどこまで対策可能なのか別発想で現在いじくり中です。object要素がらみでもまだ検証が済んでいません。戦線が広がりすぎていてちょっとアセリ気味です。apacheのmod_imapを使えるように.htaccessを変更したは良いのですが、WinIEでtype=imageなinput要素からのサーバサイドイメージマップを使う時と普通にimg要素でサーバサイドイメージマップを使う時とでIEがサーバにリクエストする引数の形式が全然違ったりして『これはIEのバグですか？』と悩んだりして１日過ごしました。仕様上許されているformのコントロールからのサーバサイドイメージマップが全然使えないですね、今のままでは。まぁ戦線が広がったので方面によっては適度に撤収します、はい。
