Stephen's Statements A little bit of everything from Stephen Duncan Jr, a Programmer/Web Geek working in the defense industry

Wednesday, September 08, 2004

Browser Spoofing: Defining The Problem

I've decided to take this issue slowly; most people's "solutions" are already assuming a certain definition of the problem, which is rarely stated.

The problem has little to do with Mozilla's ability to display remote XUL. This just makes a convincing spoof easier, although it limits the spoof to Mozilla-based browsers, and usually to a subset of versions. Similar things can be done in IE with a lot of work on some very clever styling and javascript.

The problem is this: pieces of the "chrome" (browser interface, as opposed to web-content display) can be hidden, and then fake data put in its place that trick the user into thinking that data is part of the browser.

But what things can a user be tricked into doing by mistaking content for browser? There's no danger (security-wise) in hitting a fake back-button, right? So, here's the problems I can think of:

  • The URL bar, due to passwords-as-part-of-the-url for FTP sites.
  • A browser-internal pasword dialog (such as the master-password UI)
  • Any current indicators used to help prevent page-spoofing attacks (spoofs of web-site interface, not browser interface): the security (lock) indicator, be it on the status bar, or as part of the URL bar.

I'm sure there are some potential attacks I'm missing. If you know of them, add them. If I come across them, I'll update this post to include them. As I see it, the attack fall into two categories: browser-input spoofing, and browser anti-phishing circumvention. Does that cover it? Are there other types I'm missing?


blog comments powered by Disqus