Cross-Domain requests describe requests from one domain to another. A typical example of this are Facebook information on another domain, either to display a user’s friends on the site, or even to automatically log a user into the site if still logged into Facebook.
But this example is obviously not malicious. There are two types of information that are traded that can be a problem for the Internet user. The first is privacy related. Information can be exchanged about the user’s visit, so that the other domain receives information about that visit. This is usually used for advertising purposes to track a user on the Internet.
The second is more dangerous, when malicious or undesired actions are triggered by the cross-domain request, called Cross-Site Request Forgery.
CSRF is considered very dangerous, as indicated by its ranking in the OWASP top 10 and the CWE/SANS top 25. The problem with a CSRF attack is that it makes requests on behalf of the user, without his/her knowledge. For instance, if a site (e.g. example.com) makes hidden requests to another site (e.g. myonlinebank.com), it can potentially cause harmful effects (transfer funds, create accounts, …).
The Firefox add-on CsFire protects the Internet user against malicious cross-domain requests. The add-on basically nullifies them by removing authentication information like cookies and authentication headers to eliminate the possibility that these requests can be harmful to the user.
CsFire provides a secure-by-default policy, which can be extended with fine-grained remote policies as well as fine-grained local policies. The remote policies are obtained from a policy server, to selectively allow certain harmless cross-domain requests (e.g. sharing items on facebook). The local policies allow you to specify certain cross-domain requests that should be treated differently, should you wish to do so (this is not required in normal surfing scenarios).
CsFire is based on an academic research paper CsFire: Transparent client-side mitigation of malicious cross-domain requests that was published on Engineering Secure Software and Systems 2010.
The CsFire add-on is available for all Firefox versions from Firefox 3.5 to 4.0b7. It is possible to force compatible to make it compatible with the latest nightly builds as well.
Enjoyed the article?: Then sign-up for our free newsletter or RSS feed to kick off your day with the latest technology news and tips, or share the article with your friends and contacts on Facebook or Twitter.Related Articles:
RequestPolicy For Firefox Gives You Control Over Cross-Site ConnectionsGoogle Government Requests
Cross Site Scripting
Google Implements Cross-site Request Forgery Protection
Local Rodeo Protects Firefox From JavaScript Malware
Nice find – thanks
I half take back my thanks – their server for updates is not working (404) and their documentation on how to add your own policies is very very weak.
For example, I use igoogle for my homepage and this addon disables the automatic login because of the xml request. I tried for about 30 minutes to create a rule that allowed this one request and it was an epic failure.
Seems like a good idea but the implementation needs work. Noscript does the same thing but is clunky and I have certain trust issues (for example, some of the noscript and certain ad companies are / were hard coded in the code to allow regardless of what rule you put in place), but csfire doesn’t seem ready for prime time quite yet.
i blogged about this a while back here: http://albosure.blogspot.com/2010/04/plugging-privacy-leaks-with-csfire.html
I don’t consider “malicious” attacks the only danger of cross domain requests. The major issue, in my book, is that with cross domain requests, folks like google and facebook now not only track what you’re doing on *their* sites, but everyone else’s as well! That means they have a near complete record of where you’re going all over the web! Talk about scary.
CSFire is the only solution I’ve found, but i’ve also had some small issues with it. Not sure if they come from my own config, or csfire. Anyway, definitely worth a look.
There is another solution – really quite nice called RequestPolicy
https://addons.mozilla.org/en-US/firefox/addon/9727/
It actually shows the requests; blocks by default. One click it creates a rule to block or allow – no manual create of policies. A small red flag on the bottom status bar let’s you know if there is anything to review if you want to.
Sounds pretty good, I’ll take a closer look.
Don’t bother with RequestPolicy – although the interface and use are fantastic, and it seemed to block everything it should, I also had FF3.6.11 become completely unresponsive when rules were changed (allowed to blocked again for the most part).
Once you restarted FF, all way good again.
UGGG…so much promise.
Cross domain requests themselves are only just evolving and need to be worked on quite a bit to allow for secure transfer of information between domains. Most of today’s XDRs are basically complicated JavaScript hacks and quite difficult to implement without 3rd party libraries. Fortunately a unified standard for this technique is already under development @W3C, unfortunately though only the latest browsers support it and thus it cannot be considered reliable solution just yet. Hopefully the future will bring better and safer xdrs.
Cross-Domain-Requests might be evil. Unfortunately most of them are required the way Web 2.0 is run…
So putting the burden on the user to figure out which CDR are good and which might be bad won’t work. (I personally use NoScript and RequestPolicy for quite some time…)
It requires the developers and operators of websites to specify trust relations. I personally think that Mozilla Content Security Policy is the right approach for addressing the problem.
As nice as this add-on is, I consider it won’t make the web much safer…
CsFire *looks* like a superset of what RequestPolicy can do, but I like the interface of RequestPolicy much better. And like Rick, I’ve had no joy in writing a rule to allow a site to make un-stripped requests.