WebSockets onClose allows for redirect to another site upon leaving the page




8 years ago
a year ago


(Reporter: ivo.wetzel, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-backlog])


(1 attachment, 1 obsolete attachment)

557 bytes, text/html


8 years ago
User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre

It turns out that you can do some trickery with the onClose event of a WebSocket, it seems that the order in which this is handled in comparison to window.onload etc. is broken.

Reproducible: Always

Steps to Reproduce:
1. Establish a web socket connection
2. In the onclose handler change do document.location.href = 'http://yahoo.com'
3. Click any link on the page or enter something in the address bar and hit enter
4. Search happily with Yahoo!
Actual Results:  
User is being redirect to yahoo.com upon leaving the page.

Expected Results:  
Any actions in the onclose event that affect the location should be ignored when leaving the apge.

Comment 1

8 years ago
Created attachment 481296 [details]
Redirect demo

Basic demo of the bug in action. Click the google link, you'll end up at yahoo.

Comment 2

8 years ago
Created attachment 481300 [details]
Better demo

Apparently clicking the link doesn't work 100% of the time, while using the url bar does. Seems to be a race condition, anyways, adding more socket connections makes clicking the link work reliable.
Attachment #481296 - Attachment is obsolete: true
blocking2.0: --- → ?


8 years ago
Component: General → DOM: Mozilla Extensions
Ever confirmed: true
QA Contact: general → general
Honza, care to look into this? We prevent loading other urls from onunload, we should do the same here.
Assignee: nobody → honzab.moz
blocking2.0: ? → betaN+


8 years ago
Assignee: honzab.moz → nobody
Component: DOM: Mozilla Extensions → Networking: WebSockets
QA Contact: general → networking.websockets


8 years ago
Assignee: nobody → honzab.moz
Depends on resolution of bug 616733 if this should block or not.  removing the flag for now.
blocking2.0: betaN+ → ---

Comment 5

7 years ago

Since WS is re-enabled now, we need to fix this.  I can take it if you're too busy.  Let me know.
(In reply to Jason Duell (:jduell) from comment #5)
> Honza,
> Since WS is re-enabled now, we need to fix this.  I can take it if you're
> too busy.  Let me know.

Feel free to take this bug.

Comment 7

7 years ago

Do you have any sense of what sort of security level (if any) this bug deserves?  I say "if any" because WS code is generally loaded from the server that served the page, and even when it isn't, it's loaded from a domain determined by the page-server.  So I'm not clear on how the evil use-case is for a WS redirecting during onclose.
I am less familiar with the user-facing security aspects of the browser, so I will defer to Jesse and Dan.
Whiteboard: [sg:?]


7 years ago
Blocks: 432687
Whiteboard: [sg:?]

Comment 9

7 years ago

Any sense of how urgent/serious this is?

I don't know the mechanism for how we've blocked this for XHR, so pointers to a bug would be handy if you've got them (otherwise I'll look into this when I've got 'more important' bugs in websockets--ie when I'm done bringing our protocol up to the latest version of the spec)

Comment 10

7 years ago
Not urgent. I'm pretty sure there are other ways to keep from being navigated away from (see the "eviltraps" metabug, bug 432687).
I spent an afternoon looking into this, as well as the mechanism by which we prevent changes in unload handlers. The latter works by performing checks to see if the page should allow navigation in every path in which that can occur, however when the websocket onclose handler runs (in a long-running connection that is torn down during page unloading) the page has not actually started unloading yet, so the navigation proceeds merrily on its way.
Releasing, any one feel free to take it.
Assignee: honzab.moz → nobody


7 years ago
Assignee: nobody → jduell.mcbugs

Comment 13

7 years ago
The impression I've got from bz and jruderman is that this is not a high-priority issue (there's lots of other open 'eviltraps'-see comment 10), and I got no path forward for fixing it, so I'm not going to work on it any time soon.  

I'm happy to mark WONTFIX, but got the sense that we want to eventually work on eviltraps?
Assignee: jduell.mcbugs → nobody

Comment 14

7 years ago
Hopefully this will be fixed by the same mechanism as bug 391834.
Whiteboard: [necko-backlog]
Ultimately, how is this different than having an onclick() handler on the link? A click can go anywhere and people can't trust what a link says.
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.