■WinIEだけぢゃぁないURL偽装再び。パート３

WinIEでは制限付きゾーンでもステータスバーの偽装が可能
http://d.hatena.ne.jp/hoshikuzu/20040405

WinIEでは制限付きゾーンでもステータスバーの偽装が可能となっています。昨日までは気がつきませんでしたが、大事なことですね。http-equivさんによるオリジナルなexploitはFull-Disclosureメーリングリストに投稿され、次にSecunia.comのadvisoriesに解説がのったわけですが、この時点で"Restricted Zone Status Bar Spoofing"という題名がついています。日本語に訳せば、『制限付きゾーンですらステータスバーの偽装が出来る』という趣旨になっています。セキュリティーにある程度明るいユーザが信頼できかねると思われるサイトを閲覧する前に制限付きゾーンに登録してから訪問しても、この罠にひっかかる可能性が高い、とうことになります。あるいは、既定値のインターネットゾーンにおける設定を制限付きゾーンと同じ程度にガチガチに固めていても、罠にひっかかりうる、ということを示しています。ま、ActiveScriptオフでも作動する罠、と単純に言えばそれまでですが、企業などでの各クライアントの運用設計上では問題があると思います。
制限付きゾーンでどうなるかの確認

私はStudioKamadaさんの各実験を制限付きゾーンで偽装が可能であることを確認してみました。また、自分で作成した実験でも同様です。

ただし、iframeの入れ子だけは、制限付きゾーンでは機能しません。これは、制限付きゾーンではiframeは禁止されるということでして期待される通りです。

実験のうちいくつかはSafariでも機能するとのこと、気をつけてください。＞Safariな人。
パート２以後、新しく追加された実験について

StudioKamada,captionとxmlとの組み合わせでのURL偽装では、あらたに、a要素に入れ子になったcaptionとxmlの組み合わせによる偽装が可能であること、StudioKamada,imgとmapとの組み合わせでのURL偽装では、a要素に入れ子になったイメージマップによる偽装が可能であることが明らかになりました。これらの実験はとても有益です。
ユーザスタイルシートによる防御策と新しく追加された実験について考察

captionとxmlの組み合わせにて偽装可能であることから考えますと、ユーザスタイルシートにてa要素に入れ子になった禁止すべき要素をブラックリスト的に追加していく作業の成功はかなり困難である事を示しています。これで安心、完璧、というブラックリストは難しいのではないかと思われてなりません。（私は悲観論者になりすぎているでしょうか？)

a要素に入れ子になったimgによる偽装が可能であることは、ホワイトリスト方式による罠の不可視作戦もまた座礁したことがわかります。ユーザスタイルシートにてa要素に入れ子になったimg要素を不可視にした場合には、少なくないサイトの【視覚的にのみ気の利いた】ナビゲーションを利用出来なくなります。ユーザビリティー、アクセシビリティーの面で正しく書かれているHTMLならば安心、とせめて言いたいところですが、目下のところ断言できません。ましてやユーザビリティー、アクセシビリティーに考慮を払っていないサイトが多すぎる現状を考えますと暗澹たる気持ちが湧いてきます。ホワイトリストは断念しなくてはいけないことでしょう。従いましてユーザスタイルシートによる危険物不可視作戦は中止せざるをえません。

しかしまだ若干希望があります。不可視作戦を取らずに、危険物かもしれないよと明示できるスタイルシートがあれば良いのです。はてなダイアリー - Underconstruction by Taiyo@hatena(URL偽装問題へ対処のユーザスタイルシート )でsafari用に記述されているスタイルシートは良いヒントになるかもしれません。

考慮すべきは、DHTMLは使えない、IEではいくつか使えないスタイルがある、というところでしょうか。WinIEでbeforeやafterの疑似要素が使えないことも危険物の発見警告を文字で表示できない意味で残念です。他の手を使わなくてはいけませんが思いつきません。勉強不足を痛切に感じます。
WinIE用暫定版対策ユーザースタイルシート

a *:link {color:red !important; background: #800080 !important;}
a *:visited {color:red !important; background: #800080 !important;}
a form {color:red !important; background: #800080 !important;}
a input {color:red !important; background: #800080 !important;}
a iframe {display:none !important;}

検証用のページを羅列しておきます。いずれもjavascriptオンオフ両方で念の為チェックしています。
http://www.st.ryukoku.ac.jp/~kjm/test/form2.html
http://stardust.s2.xrea.com/hatena/httpequiv/a.html
http://stardust.s2.xrea.com/hatena/httpequiv/c.html
http://stardust.s2.xrea.com/hatena/httpequiv/d.html

Kamadaさん発見のimgとmapとの組み合わせ(イメージマップ)には対応していません。WinIEではCSSの属性セレクタが使えない為に無害なイメージマップとa要素に入れ子になった有害となる可能性のあるイメージマップとを分別する手段がありません。iframeはa要素に入れ子になった怪しいものは見えません。それ以外の本日記に記載のあるexploit全てに背景色を紫としています。場合によってはローカルにあるダメダメ画像を背景にした方が良いでしょう。ブラックリスト方式ですし、イメージマップにも対応できていませんが、当面はこれにて。なお、kamadaさんご指摘のように終点アンカのa要素の開タグと閉タグに挟まれた罠ではない要素があたかも罠であるかのごとくに検出されます。このような書き方をするHTMLページは少ないかとは思います。この件、改善策があるかどうか検証中です。検討がなかなかうまくいかない理由は、WinIEにて疑似クラス(visitedなど)に対する子孫セレクタに設定したプロパティーの挙動がHTML次第で不安定（バグ）であることです。ご指摘について、以下コメント欄より引用です。kamadaさん、ご指摘ありがとうございました。

# kamada 『〜を〜で囲むのは文法的にはアウトですね。でもハイパーリンクがハイパーリンクで囲まれている部分を検出することで偽装の可能性を警告することが目的のスタイルシートがそれ以外のものに反応してしまうのは変だと思ったのです。』

# kamada 『ユーザースタイルシートで外側のaにもlink,visitedを付けておくとよいかも知れません。aだけだと誤作動する例：
http://neo.jpl.nasa.gov/neo/close.html
http://developer.ezaurus.com/sl_j/doc/software.htm
』

それにしてもイメージマップによる偽装、強烈ですねぇ。。
アドレスバー偽装をともなわないステータスバー偽装は心配しなくても良いか

アドレスバー偽装をともなわないステータスバー偽装は心配しなくても良いかについては過小評価されているような気が致します。あちらこちらで言われているphishing詐欺などの危険性についてはここでは申し上げない事とし、誰も論述しない点をこの際ですから申し上げたく思います。

クロスサイトスクリプティング脆弱性があるサイトへの攻撃の出発点としてステータスバー偽装は極めて悪用されやすい脆弱性です。一例をあげれば、method=GETで受けるCGIがあったときに、XSS脆弱性をついたURL文字列は不自然な長い文字列となりがちです。ステータスバー偽装はこの弱点をカバーしてしまいます。ひとたびXSS受動的攻撃の罠に、この出発点を悪用されてはまってしまったとしましょう。ユーザはリンクの遷移先でアドレスバーを確認できますでしょうか。慎重な人ならすることでしょう。しかし、既にドメイン内にはいったjavascriptが別のWindowを開いて汚染されたページを表示することもありえます。どうなりますか？また、そのCGIがmethod=POSTも受けているならば、出発点から遷移したリンク先でのアドレスバーの表示はひょっとしたら危険そうな文字列を含んでいないかもしれません。ステータスバーには安全そうなリンク先とみせて、その実、リンク本体はjavascriptで定義された巧妙なリダイレクトでPOSTする機能を構築されたとしたらかなり不安です。

結論として遷移先のウインドウのアドレスバーの表記は、こと、XSS脆弱性があるサイトでは役にたたないケースがあるということです。この意味で、ステータスバー偽装はアドレスバー偽装の危険を含んでいるのです。ステータスバー偽装の危険性の評価にあたっては是非この点を考慮に入れていただければと思います。
■Happy Birthday April

https://gmail.google.com/gmail/html/april.html

謎の写真。ベータだからいいや。
[コメントを書く]

# kamada 『ユーザースタイルシートで外側のaにもlink,visitedを付けておくとよいかも知れません。aだけだと誤作動する例：http://neo.jpl.nasa.gov/neo/close.html、http://developer.ezaurus.com/sl_j/doc/software.htm』

# toronei 『いわしのほうでは、コメントありがとうございました。』

# hoshikuzu 『いわしてください、、なんちゃって（＾＾』

# hoshikuzu 『kamadaさん、ユーザスタイルシートで巡回してくださったのですね！ありがとうございます。でも、まだ挙げていただいたURLで何ゆえまずくなってしまったのかよく理解できていません。例によって実力のなさを発揮しております。(^^)』

# hoshikuzu 『新しい顔文字を思いついてしまった。。モシモシ〜。。（＾＾』　　とか』

# hoshikuzu 『あ、新しいイタズラを思いついてしまった。。』(2004/04/06 09:59)
# 『名無しのごんべぇのコメントです。』

# hoshikuzu 『このイタズラはイマイチですね。』

# hoshikuzu 『kamadaさん、わかりました。終点アンカーとしてのＡ要素が閉じる前に始点アンカーのＡ要素が記述されているのですね。こーれはとんでもないHTMLです。対処が必要なのでしょうか？むむむ、です。』

# kamada 『〜を〜で囲むのは文法的にはアウトですね。でもハイパーリンクがハイパーリンクで囲まれている部分を検出することで偽装の可能性を警告することが目的のスタイルシートがそれ以外のものに反応してしまうのは変だと思ったのです。』

# hoshikuzu 『おっしゃられる通りですね。過剰防衛なのです。危険じゃないものまで検出してしまいますね。ちょっと考えているのですが、なかなか区別して検出することが難しいのです（私の実力のなさです）。新しいのを作っては見たのですが、それを破るHTML記述が見つかってしまったりします。今のところトホホ状態です。』

# kamada 『ハイパーリンクの中にハイパーリンクがあるような文法的に間違っているページに対するIEの挙動を批判している以上は、対策も文法的に間違っているかどうかよりも危険かどうか対策もなるべく厳密にしたいですよね。でも危険なものを見逃してしまうのは困ります。』

# kamada 『（途中でリターンキーを押してしまいました）対策も文法的に間違っているかどうかよりも危険かどうかを優先してなるべく厳密にしたいですよね。』

# hoshikuzu 『そうでうね、危険か危険でないかの判定の精度をあげたくて鋭意努力中です。ところで、たとえばDHTML経由ですとイメージマップタイプ偽装でもonmouseoverでＡＲＥＡがここにあるよとツールチップを出せるみたいなのです。。。ActiveXオフにてどこまで出きるかと追いかけてきましたが、ことイメージマップにはブックマークレットないしユーザスタイルシート起動でＡＲＥＡ発見できると少しマシかもしれません。』

　次へ 　前へ

ＩＴ5掲示板へ

フォローアップ:

• ユーザースタイルシートのススメ クエスチョン 2004/4/07 19:23:57 (0)

　

　

　

拍手はせず、拍手一覧を見る

---

★登録無しでコメント可能。今すぐ反映　通常 ｜動画・ツイッター等 ｜htmltag可（熟練者向）
（タグCheck ｜タグに'だけを使っている場合のcheck ｜checkしない）（各説明）

（←ペンネーム新規登録ならチェック）
↓ペンネーム（2023/11/26から必須）

↓パスワード（ペンネームに必須）

（ペンネームとパスワードは初回使用で記録、次回以降にチェック。パスワードはメモすべし。）
↓画像認証
（ 上画像文字を入力）
ルール確認＆失敗対策
画像の URL (任意):

投稿コメント全ログ 　コメント即時配信 　スレ建て依頼 　削除コメント確認方法

---

★阿修羅♪　http://www.asyura2.com/ 　since 1995
　題名には必ず「阿修羅さんへ」と記述してください。
掲示板,ＭＬを含むこのサイトすべての
一切の引用、転載、リンクを許可いたします。確認メールは不要です。
引用元リンクを表示してください。