Launchpad has imported 22 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1263100.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2016-04-08T09:06:10+00:00 Smylers-u wrote:

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 
Firefox/47.0
Build ID: 20160405015839

Steps to reproduce:

When cautiously investigating a suspicious looking email, I tried to
report a page using ‘Report deceptive site...’, but doing so just
redirected me to another spam webpage instead of the report page.

An email tricked me into opening it by claiming to be from well-known
shop Marks & Spencer, but on reading it clearly wasn't. It linked to
this page, which I cautiously opened in a private window to find out
what it was doing and whether the site should be reported:
n.mobzones.com/uk/m-s?offer=271

I clicked on the answer ‘Marks & Spencer’, which went to a page with a
really long URL (but still http:, not data: or anything funky).

Then I pressed Alt+H and chose ‘Report deceptive site...’.


Actual results:

The question popped up asking if I was sure I wanted to leave the page.

I chose ‘Leave Page’, and was redirected (via a bunch of ad networks) to
a dating website.

I went back, repeated, chose ‘Stay on Page’, and was still redirected to
the same dating site.


Expected results:

I should've reached the site for reporting the page I was on.

Ideally ‘Report deceptive site...’ wouldn't ever trigger the
confirmation for leaving the page, but if it does then ‘Leave Page’
should go to the reporting site and ‘Stay on Page’ should stay there;
neither of them should redirect to a completely different page.

(Please note I'm not saying this specific site definitely merits being
reported. Merely the form for doing so should have been displayed.)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/0

------------------------------------------------------------------------
On 2016-04-12T23:12:41+00:00 Dolske wrote:

Huh, yeah. When I load http://n.mobzones.com/uk/m-s?offer=271,
attempting to report the site does exactly what you describe. This isn't
actually a problem specifically to Report a Site, entering "google.com"
in the URL bar also results in the page somehow canceling that load and
you end up on another spam page. (http://play.leadzupc.com/...).

This seems pretty annoying, sites shouldn't be able to trap the user
like this.

Gijs/mconley: perhaps one of you could take a look to see what's
happening?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/1

------------------------------------------------------------------------
On 2016-04-12T23:17:09+00:00 Gijskruitbosch+bugs wrote:

(In reply to Justin Dolske [:Dolske] from comment #1)
> Huh, yeah. When I load http://n.mobzones.com/uk/m-s?offer=271, attempting to
> report the site does exactly what you describe. This isn't actually a
> problem specifically to Report a Site, entering "google.com" in the URL bar
> also results in the page somehow canceling that load and you end up on
> another spam page. (http://play.leadzupc.com/...).
> 
> This seems pretty annoying, sites shouldn't be able to trap the user like
> this.
> 
> Gijs/mconley: perhaps one of you could take a look to see what's happening?

This page has:

        $(window).on("beforeunload", function (e) {
            $(window).unbind("beforeunload");

            setTimeout(function () {
                window.location = url;
            }, 0);

            e.returnValue = message;
            return message;
        });


Boris, are there spec reasons we can't just stop navigation permanently as soon 
as we fire beforeunload, until either the page has been unloaded / destroyed, 
or the user explicitly decides to stay on the page?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/2

------------------------------------------------------------------------
On 2016-04-14T03:09:27+00:00 Bzbarsky wrote:

> are there spec reasons we can't just stop navigation permanently as
soon as we fire beforeunload

At first blush, per spec you can't stop navigation inside beforeunload
at all.  Or something.  Figuring out what the spec says here is rocket
science.  :(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/3

------------------------------------------------------------------------
On 2016-04-20T20:32:01+00:00 Overholt-u wrote:

Anne, can you help (see comments 2 and 3).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/4

------------------------------------------------------------------------
On 2016-04-21T10:16:28+00:00 Annevk wrote:

First of all, agreed with bz that this is in need of heavy refactoring.
Unfortunately there has been a lot of that, so I haven't gotten around
to it yet. If we had more editors, maybe...

Having read through navigate and its various associated algorithms a few
times now, I don't think anything there stops this, since the user is
allowed to navigate elsewhere until the page navigated to actually
starts arriving (at that point navigate starts blocking certain
navigation attempts, though not all).

Now, we could make tweaks, but that's tricky. E.g., if the user clicks
<a onclick=window.location='/x'>test</a> after dismissing the dialog,
should that fail or work?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/5

------------------------------------------------------------------------
On 2016-04-21T10:24:06+00:00 Gijskruitbosch+bugs wrote:

(In reply to Anne (:annevk) from comment #5)
> Now, we could make tweaks, but that's tricky. E.g., if the user clicks <a
> onclick=window.location='/x'>test</a> after dismissing the dialog, should
> that fail or work?

Can we use popup-blocker-style "allowed from user interaction, not
allowed otherwise" logic or is that problematic?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/6

------------------------------------------------------------------------
On 2016-04-21T10:32:42+00:00 Annevk wrote:

That might work, though I'm not looking forward to adding that to
something that is already impossible to understand. I guess you'd have
some document-wide-flag set during "prompting to unload" (beforeunload).
And we'd check that flag in navigation and if it's set also require the
popup check to pass. Hmm.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/7

------------------------------------------------------------------------
On 2016-04-21T14:20:05+00:00 Bzbarsky wrote:

Or we could have a "in unload prompt" flag that gets propagated to
timeouts set while that flag is set and any code those timeouts run etc.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/8

------------------------------------------------------------------------
On 2016-04-21T14:30:51+00:00 Annevk wrote:

That might be hard given the numerous other APIs we have for queuing
tasks and task-like things, no? E.g., setImmediate() if that is still
going to be a thing, or requestAnimationFrame().

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/9

------------------------------------------------------------------------
On 2016-04-21T14:49:25+00:00 Bzbarsky wrote:

Yes, I'm not saying it would be simple or easy.  :(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/10

------------------------------------------------------------------------
On 2016-04-21T14:51:33+00:00 Gijskruitbosch+bugs wrote:

(In reply to Boris Zbarsky [:bz] from comment #8)
> Or we could have a "in unload prompt" flag that gets propagated to timeouts
> set while that flag is set and any code those timeouts run etc.

var gotbeforeunload = false;
setInterval(function() {
 if (gotbeforeunload) {
   location.href = "foo";
 }
}, 100);
onbeforeunload = function() { gotbeforeunload = true; };

would defeat that, AIUI. :-(

(and I've seen patterns like this in use on trappy sites before :-( )

Really, the whole beforeunload thing needs to go away, but then there's
the rest of the web to think of. :-(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/11

------------------------------------------------------------------------
On 2016-04-21T14:52:52+00:00 Gijskruitbosch+bugs wrote:

I almost wonder if we should restrict beforeunload to https and/or a
permission...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/12

------------------------------------------------------------------------
On 2016-04-22T13:49:35+00:00 Overholt-u wrote:

It doesn't sound like we're going to be able to fix this anytime soon :(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/13

------------------------------------------------------------------------
On 2016-09-22T07:20:35+00:00 Overholt-u wrote:

*** Bug 1290834 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/14

------------------------------------------------------------------------
On 2016-10-17T09:44:45+00:00 Arni2033 wrote:

Just in case, this page prevents any navigation (including Back/Forward 
buttons):
>   data:text/html,<body 
> onbeforeunload="onbeforeunload=null;setTimeout('location.reload()',0)">

Also, bug 1283493 is probably a duplicate.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/15

------------------------------------------------------------------------
On 2016-10-17T14:19:56+00:00 Gijskruitbosch+bugs wrote:

*** Bug 1283493 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/16

------------------------------------------------------------------------
On 2016-10-17T14:20:37+00:00 Gijskruitbosch+bugs wrote:

*** Bug 839470 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/17

------------------------------------------------------------------------
On 2016-10-31T10:33:00+00:00 Gijskruitbosch+bugs wrote:

*** Bug 1313918 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/18

------------------------------------------------------------------------
On 2016-10-31T11:39:24+00:00 Gijskruitbosch+bugs wrote:

*** Bug 1313919 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/19

------------------------------------------------------------------------
On 2019-01-09T23:56:33+00:00 Gijskruitbosch+bugs wrote:

*** Bug 1518942 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/24

------------------------------------------------------------------------
On 2019-01-09T23:58:33+00:00 Gijskruitbosch+bugs wrote:

My recollection is that the current version of the spec tries to
distinguish user-initiated navigation and, once we start trying to
execute that (by firing beforeunload, followed by unload, followed by
actually loading a new page), any subsequent manipulation of location
should have no effect (unless the user bails out in beforeunload).
(Paraphrasing spec language for something roughly like this, obviously)

Boris/Anne, is that recollection at all near the truth? What should we
be doing here? And any chance we can re-prio this?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1638610/comments/25

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1638610

Title:
  Dependency of JavaScript objects is Misconfigured Browser Crashes.

Status in Mozilla Firefox:
  Confirmed
Status in firefox package in Ubuntu:
  Confirmed

Bug description:
  Hey Team ,

  The bug i want to mention here is a denial of service attack that will not 
allow any kind of redirection on a page crafted by attacker where we have used 
hyper-links(ahref). 
  The bug can be maliciously used by crafting an HTML file by an attacker and 
then sending it to the victim clearly showing there is a hyper-link that 
redirects to lets say (google.com) through status bar but it will not , instead 
cause denial of service , browser's also hang up and Crashes.
  I have tested it on the Very Latest Version of Ubuntu LTS Default Browser.

  Reason:
  The following script stops the page from being redirected:
  window.onbeforeunload = function(){
  //Unredirectable Page
  setTimeout("window.location=document.location;",0);
  }

  Demo URL : http://hackies.in/Unredirect-Browsers-Test.html

  Actual results:

  It should redirect me to the new page , where as it don't redirect to
  a new page and the browsers Hangs up.

  
  Expected results:

  So dependency of JavaScript objects(window.document) on Href attribute should 
not be there.
  Attached POC for References

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1638610/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to