It is possible to access wyciwyg:// documents without proper same domain policy checks through the use of HTTP 302 redirects, as demonstrated here: http://lcamtuf.coredump.cx/ffcache/ This enables the attacker to: steal sensitive data displayed on dynamically generated pages; perform cache poisoning; and execute own code or display own content with URL bar and SSL certificate data of the attacked page (URL spoofing++). PS. It is also possible to access wyciwyg:// through XMLHttpRequest and IFRAMEd view-source:. Although proper access control seems to be more or less exercised, this seems to be not the intended effect, judging from comments in existing code; and the mechanism can be used by rogue sites to conveniently tag visitors regardless of cookie restrictions (write a unique ID to a wyciwyg:// file with document.write(), then do XMLHttpRequest on returning visitors), so you might want to tighten it.
In Minefield (latest trunk), I get : "Something went wrong - my redirection trick didn't work. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070804 Minefield/3.0a7pre
I get the "trick didn't work" dialog with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20070701 BonEcho/126.96.36.199pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070804 Minefield/3.0a7pre Is there something wrong with the testcase?
Hmm. On trunk this won't work; any place that actually does security checks (and that should be all of them, of course) won't allow wyciwyg loads. We should probably fix this on branch.
Created attachment 271479 [details] [diff] [review] Like so As far as I can tell, with this patch we can still go back to document.written pages, so history loads work as they should.
10 years ago
10 years ago
Gavin, no clue about trunk (Boris is probably right). Boris, I take you could reproduce this on branch? If you have problems, make sure you visited the "beaver bank" site and clicked "login"; if you did, the only thing to check is whether a wyciwyg://0/http://beaverbank.dione.cc/ document got created (say, view -> page source, then see the title bar of the viewer window). "Trick didn't work" error (and a "page moved" pop-up window) simply means that HTTP 302 Redirect to Location: wyciwyg://0/http://beaverbank.dione.cc/ did not go as planned.
Yeah, I could reproduce this on branch. And I get the expected security error with the patch.
(In reply to comment #5) > If you have problems, make sure you visited the "beaver bank" site and clicked > "login"; if you did, the only thing to check is whether a > wyciwyg://0/http://beaverbank.dione.cc/ document got created (say, view -> page > source, then see the title bar of the viewer window). I did visit the "beaver bank" site, and I did click login. The URI I saw when viewing the page's source was of the form "wyciwyg://0/http://beaverbank.dione.cc/", but the "0" was "19", and increased to "20" when I cleared my cache and tried to reproduce again. That explains why your testcase isn't working for me, I guess (it seems to assume the URL will contain "0").
(In reply to comment #7) > it seems to assume the URL will contain "0" Yup; it usually does, but if not, could be quickly brute-forced by an exploit. /mz
Comment on attachment 271479 [details] [diff] [review] Like so r=dveditz approved for 188.8.131.52 and 184.108.40.206, a=dveditz for release-drivers
Fixed on both branches.
"stealing sensitive data" should be sg:high (possibly lowered to sg:moderate if it's a completely unreliable attack, involves unlikely user interaction, or not really any potential victim sites matching the criteria. There are enough ajaxy sites potentially vulnerable to stick with 'high')
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:220.127.116.11) Gecko/20070515 Firefox/18.104.22.168 - Build ID: 2007051502 bug doesn't work
Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20070710 BonEcho/126.96.36.199pre. In a build from 2007-07-09 without the patch, the content gets injected and the attack is successful, but with the above build, the attack fails and I get the security error Boris mentioned.