It's probably OK to replace the URL of the previous page if it otherwise doesn't interfere with the ongoing navigation. The old attacks predated the pushState / replaceStates API altogether.
/mz On Sun, Nov 2, 2014 at 1:43 PM, cowwoc <cow...@bbs.darktech.org> wrote: > 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
