Re: [whatwg] Modifying the URL inside beforeunload event

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 <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