W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] Modifying the URL inside beforeunload event

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Sun, 2 Nov 2014 13:53:27 -0800
Message-ID: <CALx_OUBPJnnbcacwFHQ_XQeeuqvUrVsuk3Hc2WBrTe9oSnB5JQ@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: WHATWG <whatwg@whatwg.org>
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.


On Sun, Nov 2, 2014 at 1:43 PM, cowwoc <cowwoc@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
Received on Sunday, 2 November 2014 21:54:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:26 UTC