Archived Blog
eTLD - Effective Top-Level Domains
This security fix restricts broad-domain cookies so that cookies are restricted to a single domain. Cookies have a domain attribute, which you can use to define its use and accessibility. For example, xyz.example.com can issue a cookie with domain=.example.com. The cookie can be used on example.com or any of its sub-domains. However, RFC restrictions prevent abuse of issuing cookies with attributes such as domain=.com, which would allow use of the cookie on any .com domain. A problem occurs with some countries that have domains such as co.uk. You can set a cookie that can be used on every .co.uk Web site. Internet Explorer tried to combat this problem by restricting cookies so that the 2nd level domain has to be greater than two characters (e.g., .co.uk cannot be used), and blacklisted some other known similar domains. Some other, less known domains are left unprotected by this attempt, such as .com.fr or .edu.ge. A clear, example attack was provided on bugzilla, and can be illustrated as follows:
1) assume a safe site on the .com.fr domain, such as http://good.com.fr
2) assume an evil site on the .com.fr domain, such as http://evil.com.fr
3) if the user visits http://evil.com.fr, it can set a cookie with domain=.com.fr
4) this cookie is now used on every .com.fr domain, including good.com.fr
The attacker probably will then use this cookie to authenticate. By creating this list of TLD's, Firefox easily can determine which cookies should be restricted. For example, if .com.br is a valid TLD, then restrict all cookies with domain=.com.br.
Malware & Phishing Protection
Firefox now reports when you attempt to visit an attack site which may steal your information or cause damage to your system or other systems. For example:
Firefox uses the Google Safe Browsing Service/API, which contains lists of malicious pages or phishing sites. Firefox makes a POST request on your behalf to the API, which returns a set of URL hashes. These are either categorized as malware, phishing, or as a whitelisted domain. When a user visits a Web site, a hash is taken of that URL, and then compared against this list to see if access should be granted or denied. The response also contains the update interval, denoting the next time your browser is allowed to request for possible updates.
This protection is as only as good as its blacklist, and while we found that some of the phishing URLs tested were indeed blocked, we found multiple phishing pages that still made it through:
Click here for more details on the Safe Browsing API.
Prevention of Global Object Redeclaration
Firefox 3 is is the only browser with this security feature, as it is the only browser that uses JavaScript v1.8. JavaScript prevents you from re-declaring global objects such as Array. For example, the following JavaScript would cause an error:
function Array(){
alert("redeclared"); //error
}
This prevention was implemented due to security concerns of "data leakage." Attackers could access data in JSON requests, such as data residing in an Array type object. Click here to learn about securing JSON.
Restriction of Cross-Site XMLHttpRequest Object
In a previous blog, we indicated that cross-site requests in this manner violate the SOP (Same Origin Policy), and can create some security concerns. However, this feature also opens many opportunities in terms of product development. At the time of writing the previous blog, both Firefox and Internet Explorer had such capabilities. However, the cross-site XHR object was pulled in the final release of Firefox 3. This functionality now only can be used by Firefox extensions, and cannot be used in the standard scripting environment, as described on the Mozilla Dev Center Web page.
Security Researcher: Joren McReynolds
