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 が表示されるが、実際にクリックすると中の「リンクとして機能する何か」が機能してしまうため、ステータスバーの表示と遷移先が食い違うというお話ですね。そして、「リンクとして機能する何か」には、
- スタイルシートでアンカーっぽい見た目を与えられた submitボタン
- iframeで埋め込まれた、別ページのアンカー
- クライアント側イメージマップ
- tableの中 (th, td, caption の中) に入れ子になったアンカー
など様々なものが該当し、無数のパターンがあるため簡単には回避できないと。
aの中に form やら table やらが入ると valid にならないのですが、MSIEは例によって気を利かせてくれるので、攻撃者の望む世界が実現できます。少なくともアンカーや form まわりについては、invalid なものはことごとくエラーにした方が良いのではないかと思いますが……実は a の中の input なんかは DTD 的には OK だったりするので何とも。
ユーザ側の対応としては、「ステータスバーを信用しない」に尽きます。この攻撃はこの前の URL 偽装問題と異なり、リンク先ページの URL 入力欄を改竄することはできません。そのため、リンク先の URL をちゃんと確認すれば問題はないでしょう。もちろん、URL 欄を隠しているようなサイトは使用しないということになりますが、これは昔からの鉄則でしょうから問題ありませんね。
- 「URL偽装問題再び?」へのコメント (7件)
関連する話題: セキュリティ / Microsoft / Internet Explorer / HTML
- 前(古い): エイプリルフール
- 次(新しい): www.accsjp.or.jp また Aレコード削除