Mozilla released its latest browser, Firefox 3.0, this week. SecurityFocus contributor Federico Biancuzzi tracked down two key members of Mozilla's security team, Window Snyder and Johnathan Nightingale, to learn more about the security features included in this major release.
SecurityFocus: Could you introduce yourself?
Window Snyder: I'm the Chief Security Something-or-Other for Mozilla. I work on security strategy, engineering, and communications.
Johnathan Nightingale: My business cards say "Human Shield" but if they were more boring they'd say, "Security User Interface (UI) Lead." My job is to design and implement parts of the browser front-end that help users know who they're dealing with online, and whether their interactions are safe ones. I also represent Mozilla in standards groups on topics of security and usability. As long as I'm annoying an equal number of usability people and security people, I figure I'm doing my job.
Does Firefox 3.0 include any protection against phishing?
Window Snyder: Anti-phishing protection was introduced in Firefox 2.0. It has been very successful in helping users recognize when they've been lured to a site that is masquerading as a well-known legitimate site. To build upon this we've created an interface that enables users to get more information about the site they are visiting by clicking on the favicon in the location bar. This also includes a mechanism to identify Extended Validation Certificates or EV Certs. These certificates are issued to entities after a much more robust identification process than a regular cert. When you visit a site that presents an EV Cert Firefox will display that information in the one-click favicon to make it easier to identify the site you're visiting.
In Firefox 3 we've also added malware protection to prevent users from visiting sites that contain malicious software. If a user stumbles accross a site that has been identified as a site that contains malware, Firefox will prevent the page from loading, and display a page that informs the user that malware has been detected. To further protect users, there's no easy way for the user to accidentally click through the warning.
How does Firefox 3 recognize a "web site that is known to install malware" or a "page that's suspected of being a forgery"?
Johnathan Nightingale: For Firefox 3, we have an agreement in place with Google to use their phishing and malware databases. We pull updates to a local DB about every 30 minutes, and use that to check the sites a user visits before loading. Because we can do that lookup quickly and locally before even connecting to the site we can block the load up front, which is pretty massively preferable to just popping a warning up over the loaded page content. This way even attacks which exploit a flaw in low-level things like the network stack don't get a chance to work, you remain protected. After all, the best way to thwart bad people is to present zero attack surface whenever possible.
How does anti-virus integration work?
Window Snyder: Firefox enables anti-virus tools to work in concert with the browser to check executable as they are downloaded for potential viruses or malware. When a user initiates a download, Firefox informs the anti-virus software so it can check the executable before it can harm the user's machine.
I am a bit puzzled by this new feature: "Web-based protocol handlers. Web applications, such as your favorite web mail provider, can now be used instead of desktop applications for handling
mailto: links from other sites. Similar support is provided for other protocols as well. (Note that web applications do have to register themselves with Firefox before this will work.)". How does this registration process between Firefox and "web applications" work?
Johnathan Nightingale: As you mention, web-based protocol handlers basically let you say things like "I use a webmail provider, so when I click on mailto: links, go there, instead of opening my mail client" which we think is pretty handy. The registration API is very simple, the site just needs to tell us:
- What protocol do you want to handle?
- What URL should that redirect to?
- What do you call yourself?
We do, however, have safeguards in place to prevent bad behavior. The user has to consent to this registration in the first place, and a site can't register a handler that lives on a different domain (so, for example, a vulnerability that let people inject JS into a hotmail message couldn't masquerade as hotmail but actually send
mailto: requests elsewhere). Registrations are non-exclusive, so registering your new handler isn't going to bump out my previous handler, except of course that you don't get to register for protocols that we handle