Re: [whatwg] Modifying the URL inside beforeunload event

Hi Michal,

I'm relatively new to this mailing list. How do proposals make their way 
to action items here?

Thanks,
Gili

On 02/11/2014 4:53 PM, Michal Zalewski wrote:
> 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 Tuesday, 4 November 2014 14:35:35 UTC