Blake Kaplan (:mrbkap) (inactive) Reporter
	Description • 18 years ago

In bug 344495, moz_bug_r_a4 uses a setter on window.location.href to attack gmail (or any other top.location.href setting site). In that bug, I was investigating the security checks performed at each step of the way, attempting to make one of them fail (correctly). While I still believe that such a fix is viable, I also came up with this secondary idea:

Currently, we use XPCNativeWrapper to protect chrome that wants to touch content from evil, content-defined setters tricking chrome into doing something it didn't expect to do. The question that I started asking, was "why can't XPCNativeWrappers do the same service for cross-origin accesses?" After talking with bz and brendan, I think this sounds like a viable option. We could wrap returned objects with XPCNativeWrappers, so that the testcases in bug 344495 wouldn't ever call the malicious page's setters.

Making this change will involve ensuring that we don't lose any functionality and don't introduce any XSS attacks through XPCNativeWrapper. We might also have to be careful to not share the same XPCNativeWrapper between chrome and content, but that's unclear.

I noticed one other problem when thinking about this: given the script:
w = window.open();
w.location.href = 'http://some.other.domain'
w.location.href = 'foo'

we'd want w to be an XPCNativeWrapper, but wouldn't know to wrap it at the assignment (at window.open()). We'll need to figure out how to get around that problem, since the second set of w.location.href could be hijacked. Other observations or problems are welcomed.

	Blake Kaplan (:mrbkap) (inactive) Reporter
	Comment 1 • 16 years ago

I'd say this is done now.