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:188.8.131.52pre) Gecko/20070701 BonEcho/184.108.40.206pre 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.
Assignee: nobody → dveditz
OS: Windows XP → All
Product: Firefox → Core
QA Contact: firefox → toolkit
Version: 2.0 Branch → 1.8 Branch
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.
Assignee: dveditz → bzbarsky
Priority: -- → P1
Summary: unauthorized access to wyciwyg:// documents possible → [FIX]unauthorized access to wyciwyg:// documents possible
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 220.127.116.11 and 18.104.22.168, a=dveditz for release-drivers
Attachment #271479 - Flags: superreview?(jst) → superreview+
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')
Whiteboard: [sg:low] → [sg:high]
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:22.214.171.124) Gecko/20070515 Firefox/126.96.36.199 - Build ID: 2007051502 bug doesn't work
Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20070710 BonEcho/184.108.40.206pre. 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.
You need to log in before you can comment on or make changes to this bug.