Some time ago I was reading the article Session Destroyer: Automatic Webapp Session Invalidation from the Linux Journal. It was a neat idea, however the part which peeked my interest was the following:
Mozilla Firefox does not protect you against this attack by default. However, Google Chrome supposedly does because they implement each tab in it's own virtual sandbox.
I tried to search around, but didn’t find any results which seemed relevant, so I went ahead and did some experimentation on my own. The results are:
- No, Google Chrome doesn’t introduce further sandboxing to passing cookies between requests coming from different sites (this is the main reason for CSRF). I tested this in all the process modes available for Chrome (and it is logical that they all behave the same, since the passing or not of cookies is a “higher level” policiy”)
- I also tried it with IE 8, the other browser at the moment which uses processes to separate out tasks. Besides being much slower, it didn’t show different results. (BTW, I did the comparison with the “process-per-tab” mode for Chrome to compare oranges to oranges, and it still was considerably slower!)
The conclusion? The initial comment was made probably because of a misunderstanding. Still, a solution of this sort might be useful. What I’m pondering here:
- each tab has a “zone”. The zone is determined by the FQDN of the address entered in the address bar (ie. clicking on links doesn’t change the zone).
- cookies are sent with the request only if the site which set the cookie and site which is sending the cookie are in the same “zone” as specified by the same origin policy
What does this brake? Probably some Web 2.0 widgety type things (in the sense that they have to revert back to the “copy this snippet over there” more or require an extra login – both of which are tolerable). However it may also break situations where people navigate using search engines (ie. they don’t enter the address but rather search for it).
No comments:
Post a Comment
Comments Section