■ - hoshikuzu | star_dust の書斎

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

WinIEでは制限付きゾーンでもステータスバーの偽装が可能

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;}

以上は旧バージョンです。旧バージョンでは見落としでhttp://stardust.s2.xrea.com/hatena/httpequiv/e.htmlが対処出来ていませんでした。また、終点アンカーとしてのa要素の開タグと閉タグに挟まれた安全な始点アンカーを危険であると誤検知していたバグを修正しました。新しいバージョンは以下の通りです。あいかわらずブラックリスト方式ですしイメージアップによる偽装は検知できません。なお、この修正により、アンカー入れ子系と画像とのミックスを対処する為不可避的に、従来では紫に染めていたものを見えなくなるように変更せざるをえませんでした。ただし、FORM部品は紫に染まります。(4/8)


a:link form {background-color: #800080 !important;}
a:visited form {background-color : #800080 !important;}
a:link button {background-color : #800080 !important;}
a:visited button {background-color : #800080 !important;}
a:link input {background-color : #800080 !important;}
a:visited input {background-color : #800080 !important;}

a:link *:link {visibility:hidden !important;}
a:visited *:link {visibility:hidden !important;}
a:link *:visited {visibility:hidden !important;}
a:visited *:visited {visibility:hidden !important;}

a:link iframe {visibility:hidden !important;}
a:visited iframe {visibility:hidden !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
http://stardust.s2.xrea.com/hatena/httpequiv/e.html

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

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

# 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

謎の写真。ベータだからいいや。