CsFire, Protects Against Malicious Cross-Domain Requests In Firefox
Cross-Domain requests describe requests from one domain to another. A typical example of this are Facebook information on another domain, to display a site's followers for example or advertisement from third-party advertising companies.
But those 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 your visit so that another entity receives information about that visit. This is usually used for advertising purposes to track a user on the Internet.
Considering that you reveal information as soon as you connect to a site or server, and that information includes your IP address, location in the world, operating system or language, it is fair to say that this is a privacy issue.
The second is more dangerous: malicious or undesired actions can be triggered by cross-domain request like Cross-Site Request Forgery attacks.
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 Internet users against malicious cross-domain requests. The add-on 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 the latest. It is possible to force compatible to make it compatible with the latest nightly builds as well.
Update: CsFire has not been updated since 2012 and it is unclear at this point in time if it still works in recent versions of the Firefox browser. While it is still possible to install the extension, it is unclear if all features work as advertised. Some that are visible do including the log file and the remote server update feature.
With that said, it appears that the add-on is abandoned and won't receive updates anymore.
Hmm…it might be time for me to take another look at CsFire. Since version 1.0, it has used a new and smarter algorithm to figure out which requests to trust by default, so it should have far less false positives.
Basically, if site A has sent a POST or redirect to site B (eg if a shop has sent the user to Paypal), then site B is allowed to send authenticated requests back to site A (so Paypal can report back to the shop that the user has paid). This should make most legitimate scenarios Just Work.
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.
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…
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.
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.
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.
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.
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.
Nice find – thanks