Security/Reviews/Firefox4/Cookie Security Review
The scope of cookie changes in Firefox 4 is much smaller than I (dveditz) originally thought. Rather than completely strike it from the security review schedule dwitte and I conducted an informal one-on-one overview.
Privacy oriented--potentially site-breaking--changes such as double-keying 3rd-party cookies were dropped. There were essentially two changes:
- the site cookie quota is per eTLD+1 rather than individual host.
- global cookie limit is elastic
Changing the site cookie quota to aggregate by eTLD+1 prevents one malicious site from creating an unending number of subdomains in order to flush all your cookies (which can be a prelude to a session fixation attack, or simply an annoying mass logout prank). That attack in Firefox 4 will now all count toward a single site limit, protecting the cookies of other sites.
Because multiple individual hosts are all now contributing to the same "domain" limit some larger web properties were losing cookies at the pervious 50-cookie limit (two and a half site's worth of the historical 20-cookie limit). The quota per eTLD+1 was raised to 150. In Firefox 3.6 it would take 60 hosts @ 50-cookies to reach the global limit. In Firefox 4 it takes 20 eTLD+1's @ 150-cookies to reach that limit.
The other major change was an elastic global limit. Even with the eTLD+1 aggregation it isn't a very expensive attack to register 60 domains to flush someone's cookies, and 20 registrations is even cheaper. Now when the global limit of 3000 cookies is reached then cookies are purged, but only those cookies which have not been used in 30 days. The primary goal of this change is not security, it was simply to accommodate some exceptionally active web surfers who seem to collect lots of cookies and were getting logged out of their sites. But it does have the security benefit of preventing cookie flushing as an attack or attack prelude.
The downside is that what was formerly a cookie-flushing attack can now be a denial-of-service attack, an attempt to fill memory and disk (memory is likely to give way first). It would be an expensive attack. Rounding 4K max cookie size up to 5K arbitrarily to more than account for hash-table/database overhead each eTLD+1 registered domain could use up 750K. It would take about 1400 registered domains to eat up a Gigabyte.
There is a new hidden pref for a feature that was attempted and then dropped: you can set third-party cookies to session-only without having to set first-party cookies that way or blocking third-party cookies outright (the only previous option). I believe there were issues with sites that you visited as both first-party and third-party -- when you visited them as third-party it would change your permanent cookies to session and then they would get lost. In many cases this is what you want. If third-party cookies did not convert existing first-party cookies then "evil trackers" would only have to find a way to set a first-party cookie and then the setting is irrelevant to them. In other cases this means the "remember me" checkboxes aren't going to work when logging into some popular sites who also have third-party content, like Facebook or Google.
Data migration
The cookie database schema changed in Firefox 4. If you use a Firefox 4 database in Firefox 3.6 the existing cookies should be read fine and the extra columns will be ignored.
If you add new cookies in Firefox 3.6 then the new columns will get nulls. One of these columns is the eTLD+1 domain, which is used in Firefox 4 to look up cookies. The net effect will be that the cookies added in Firefox 3.6 will be invisible in Firefox 4 when counting up the quota or when deciding which cookies to send to the site. They will stay in the database until they expire or until the 3000-cookie global limit is reached and they are purged after 30-days. They will show up in the cookie viewer though (which still operates by hostname and not eTLD+1) so they could also be individually deleted.
Tunables
The various limits described above can be adjusted by users with the following hidden prefs. "purgeAge" and "thirdparty.sessionOnly" are new, "maxPerHost" has a new default of 150
- network.cookie.maxNumber
- network.cookie.maxPerHost
- network.cookie.purgeAge
- network.cookie.thirdparty.sessionOnly
Issues
- is 150 the right "domain" limit or too high?
- is it possible to get Test Pilot data on this?
- is 30 days too long for the purge age?
- does mobile need stricter limits to protect against DoS?
