- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Sun, 02 Nov 2014 16:43:12 -0500
- To: Michal Zalewski <lcamtuf@coredump.cx>
- Cc: WHATWG <whatwg@whatwg.org>
On 02/11/2014 12:28 PM, Michal Zalewski wrote: >> I believe I have a legitimate use-case (described in comment #9) for needing >> to change the URL in "beforeunload". > I am probably at least partly to blame for the browsers not letting > you do that - I reported several onbeforeunload attacks some 8 years > ago. Sorry!:-) > > In general, there is a security-driven desire to prevent a website > from "trapping" visitors and not allowing them to navigate away. This > not just a matter of nuisance attacks, but when employed in a clever > way, can be a powerful tool for phishing if you can convince the user > to type in a known URL and then spoof the page transition. > > If we end up allowing navigation to be aborted or modified from within > unload-related events, we need to keep that in mind. > > /mz Hi Michal, I had a feeling this was security related :) Correct me if I'm wrong, but don't the attacks you mentioned rely upon access to history.back()/forward()? Would it be safe to allow history.replaceState() while forbidding the other two? Meaning, we would allow a page to rewrite its own address but not other pages' addresses. Gili
Received on Sunday, 2 November 2014 21:43:55 UTC