We want to encourage the discovery of security issues within our web applications with the goal of keeping our users safe. We also want to reward security researchers for their efforts with the hope of furthering constructive security research.

This new policy will go into effect starting December 15th, 2010 PST, and any new web application bugs will fall under this new policy. It is important to note that nothing else has changed with the original security bounty program and the updated amount which was announced back in July.

The Web Security Bounty FAQ includes which types of vulnerabilities will be considered and which sites will be considered to be apart of the Web Application Bounty Program.

The full text of the security bounty program:
http://www.mozilla.org/security/bug-bounty.html

Chris Lyon
Director of Infrastructure Security

The introduction of this tool reinforces the importance of websites configuring themselves to require secure connections.

Not too long ago we announced HTTP Strict-Transport-Security that can be used to — among other things — ensure your Facebook or Twitter cookies can’t be sniffed by someone using a tool like Firesheep. In fact, it’s built into Firefox 4. To protect their users from the this attack, a site simply needs to set the Strict-Transport-Security HTTP header when they serve you a secure log-in page, and make the rest of their site available over HTTPS. Firefox will take care of the rest: automatically fetching that site over a secure connection and blocking any third parties from seeing the unencrypted traffic.

We recommend that website authors make use of this header in order to protect their users.

But this technology is new to Firefox 4. To get HTTP Strict-Transport-Security support in Firefox 3.6, you will need to install an add-on that implements it such as ForceTLS. ForceTLS also gives you a way to opt-in to this extra security for sites who haven’t yet started sending that helpful HTTP header; it provides a user interface to add and remove sites that should never be contacted insecurely. Both HSTS and the manual opt-in are also available as part of NoScript. However, manually opting-in to HSTS on a site which does not yet make itself fully available securely may break the site; not all sites are ready for secure access.

If you are already using Firefox 4 beta or nightly versions, you can enable the additional controls with the STS-UI add-on. While the core Strict-Transport-Security features are already built into Firefox 4, this UI gives advanced users the ability to further ensure the security of their connections.

Sid Stamm
Conspiracy Theorist

A website can choose to include the x-frame-options header to protect against malicious framing of web content by third parties. For example a malicious site might frame a website from another domain and surround the framed site with advertisements. Alternatively, a malicious site could use a CSS layer attack called ClickJacking to trick users into performing unintended actions within the framed website that is obscured by overlaid CSS layers.

The x-frame-options header supports the following values:
SAMEORIGIN – allows only sites from the same domain to frame the page
DENY – prevents any site from framing the page

Additional Reading:
Mozilla Developer Network article
Microsoft Developer Network article
OWASP Clickjacking Article

Michael Coates
Web Security

HTTP Man-In-The-Middle (MITM) attacks

Consider your typical online banking session:  you type “www.mybank.com” into the address bar, hit enter, and wait for the site to load.  When it shows up, you enter your password, do your banking, then log out.  This process is more-or-less automatic for many people, and the subtleties of the process disappear in the background.  More specifically, these are the steps for logging into the bank’s site:

1.   You type “www.mybank.com” into the address bar and hit enter.
2.   The browser assumes “www.mybank.com” should be requested over HTTP by default, so the initial request is unencrypted.
3.   The server at “http://www.mybank.com” responds with an HTTP redirect to “https://www.mybank.com”
4.   The secure connection is established, and a login page is served via HTTPS.
5.   You enter your password and do your banking.

It is only after the first few swift (and often unnoticed) steps that the user is presented with a secure connection.  In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen.  Many users might not notice this and end up logging into an attacker’s website.

HTTPS is intended for both channel encryption, to thwart eavesdroppers, and for server authentication.  In the hotspot banking MITM situation, you may simply assume that no errors indicates a safe connection but in all reality the server has not been authenticated!   After all, you’re not presented with any warnings or UI indicators saying the site is an attack site.  If you’re a diligent user, you can always click Firefox’s site identity button to find out whether or not the site has authenticated itself and whether it’s encrypting to prevent eavesdropping, of course.  It’s hard to remember (and time consuming) to do that every time, especially when you’re used to logging into certain trustworthy sites automatically.  And in fact, a fake bank’s site may even have a little lock icon next to the login box that assures the user he is logging into a secure site –  many legitimate banking sites unfortunately do the same thing.

Asking the Browser to use HTTPS Only

To stop this kind of man-in-the-middle attack, where an HTTPS site is mimicked over HTTP, Collin Jackson and Adam Barth proposed something called ForceHTTPS in 2008.  This is a browser feature that allows web sites to tell a browser to always request it via HTTPS, and never unencrypted HTTP.  It was intended to help eliminate the redirect from HTTP to HTTPS and minimize the chance of an insecure attack as described above.

We like the idea of ForceHTTPS and are working on implementing it as “ForceTLS” in Firefox with hopes it will reduce occurrences of MITM attacks and generally improve user security.  We built an add-on as a first step prototype of the feature that works in a similar fashion to the original design by Jackson and Barth.  Instead of using cookies, however, we’re asking sites to send an HTTP header “X-Force-TLS” with any securely-transmitted response.  The name of this header will change in the future, but for now we’re using “X-Force-TLS” as the experimental header that, when present, means:

1. The browser should only attempt to access that domain via HTTPS
2. How long this requirement should last. For example, a server can ask the HTTPS-only request to expire after three days.  This expiration timer can be reset or changed every time data is served to the client by providing a new HTTP header.
3. Whether or not subdomains of the requested site (images.mybank.com, or login.mybank.com for example) should also be forced into HTTPS

ForceTLS can be used for more than just protection against evil hotspots; it can also be used to harden web applications against accidental unencrypted requests.  Many popular web apps can be used over both secure HTTPS and insecure HTTP connections; while you’re given the choice to pick HTTPS instead of HTTP, it’s possible that a large web app might have a HTTP URI referenced from some subtle corner of its code (by accident of course), and with Force TLS employed, this would quietly get upgraded to HTTPS and prevent exposing any unencrypted data on the network.

Check out our prototype, and tell us what you think!  The browser extension and source code are available on AMO (https://addons.mozilla.org/en-US/firefox/addon/12714).

Sid Stamm
Securinator

Fuzzers are a tool that we’ve found incredibly valuable in the past, and continue to employ heavily. A fuzzer’s job is to make your application fail by feeding it surprising inputs. The good ones do this by knowing a part of your code well enough that they can make smart guesses about how to confuse it. This one, for instance, produces a constant stream of mostly-correct CSS rules, and watches to see whether the browser can cope with them. Because fuzzers take these random paths, they can uncover subtle bugs that are rarely encountered during “normal” testing; and Jesse is a master at building them.

When Jesse originally started talking about his javascript fuzzer, he gave it to other browser vendors first, and he’s done the same with this one. If you’re interested in automated security analysis tools though, he’s now made it public, and I recommend checking it out.

Johnathan Nightingale
Human Shield