水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > URL偽装問題再び?

URL偽装問題再び?

2004年4月5日(月曜日)

URL偽装問題再び?

URL偽装問題再び――IEとOutlookに (www.itmedia.co.jp)」というお話が出ています。スターダストさんの所 (「WinIEだけじゃぁないURL偽装再び。 (d.hatena.ne.jp)」「WinIEだけじゃぁないURL偽装再び。パート2 (d.hatena.ne.jp)」「WinIEだけじゃぁないURL偽装再び。パート3 (d.hatena.ne.jp)」) にも情報がたくさん。

要するに、「リンクとして機能する何か」を a要素の中に入れると、ステータスバーには外側の a要素のリンク先 URL が表示されるが、実際にクリックすると中の「リンクとして機能する何か」が機能してしまうため、ステータスバーの表示と遷移先が食い違うというお話ですね。そして、「リンクとして機能する何か」には、

など様々なものが該当し、無数のパターンがあるため簡単には回避できないと。

aの中に form やら table やらが入ると valid にならないのですが、MSIEは例によって気を利かせてくれるので、攻撃者の望む世界が実現できます。少なくともアンカーや form まわりについては、invalid なものはことごとくエラーにした方が良いのではないかと思いますが……実は a の中の input なんかは DTD 的には OK だったりするので何とも。

ユーザ側の対応としては、「ステータスバーを信用しない」に尽きます。この攻撃はこの前の URL 偽装問題と異なり、リンク先ページの URL 入力欄を改竄することはできません。そのため、リンク先の URL をちゃんと確認すれば問題はないでしょう。もちろん、URL 欄を隠しているようなサイトは使用しないということになりますが、これは昔からの鉄則でしょうから問題ありませんね。

関連する話題: セキュリティ / Microsoft / Internet Explorer / HTML

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 Webプログラミング

その他サイト