227338 - popup blocking can be evaded by forcing popups on clicked links

Status: RESOLVED DUPLICATE of bug 212163

(Core :: General, defect)

Description

[Kevin Stange]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+

This URL demonstrates a popup blocker evasion system which uses the clicking of
any link on the page as a trigger to open a popup.  This could probably be
dealth with by preventing popup windows from being created by scripts that also
continue to open a link (but this might night be the designed behavior).  This
one is tricky, but it would be wise to handle if possible.

Reproducible: Always

Steps to Reproduce:
1. Go to the URL with Firebird
2. Note that an active blocker was detected.
3. Click a link and get a free ad.

Comment 1

[Dan M]

Kevin, thanks for being on the lookout for sites that defeat popup blocking.
There are several known vulnerabilities and no doubt some more that aren't
known. We'd like at least to have them enumerated in bugzilla. But this
particular case really isn't an example.

For starters, I'd be embarrassed to publish the clumsy sample script they tout
at adoutput.com. (That said, they deserve credit for (presumably) finding
something that works on all browsers. But the structure of the code tells me it
was built by random accretion of test cases and the result is actually funny, in
a geeky kind of way. I'd lay money that even they don't understand how it really
works.)

Ahem. But more importantly, what they're doing, it's not popups at all. It's
instructions for building a website that opens a new window every time the
visitor clicks a link on the site. Any moron can do that. There's no trick to
it. adoutput's code saves the website author the trouble of typing a secondary
clickhandler into every link, is all.

By definition, popup windows are those that open unexpectedly, in the absence of
any user action. It's a perfectly valid action to open a new window in response
to the user clicking a link. We don't want to disable that functionality.

I suppose some users would appreciate it if content script were under no
circumstances ever able to open a new window. Actually I find that kind of
appealing, myself. But if we want to open that door, that would be an
enhancement request bug.

In the meantime, barring actual defeat of the popup blocking code, if the
visitor to such a site has popups blocked, new windows can be opened but only in
response to clicking a link. The new windows can't themselves be used to spawn a
popup cascade, so they can be closed without repercussions. The new windows
can't really be stopped, since it's just code running directly in a
clickhandler. Many legitimate sites would break were that disabled. But at least
minimal damage is done.

Comment 2

[Dan M]

The same problem rears up again in bug 230500. So I'm expounding on my previous
comment with the idea that we may have to do something about this.

Restating, this script (and the one in 230500) is equivalent to simply writing a
web page with click handlers that open popups. If we hamstring script in the
name of popup protection, people will simply begin hardcoding these
clickhandlers. Worse, we become incompatible with legitimate websites. It's out
of the question.

CNN pages, for instance, are swimming with legitimate links that read <a
href="javascript:LaunchVideo(...)"> or <a href="javascript:CNN_openPopup(...)">.
They could just as easily have been written using a click handler. And though
services like adoutput.com make it easy for naive webmasters to strew popup
click handlers throughout their site, it's not much more difficult to hardcode
it, without script. Or to script it server-side. These exploits will follow if
we somehow find a way to suppress this one.

Still, gotta admit, new windows I didn't ask for are hazardous to my blood
pressure. In the realm of off-by-default, geek-only features, the only solution
I can think of is to add another level to popup blocking: 

( ) block unrequested popup windows
(*) block all freaking new windows from user script, every one

and tie it in with some sort of extemporaneous override, similar to bug 222763.
Also helpful would be the morning after override, bug 198846 / bug 176564.
(Though 222763 requests the opposite capability, it's the same idea.)

Comment 3

[Dan M]

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

Comment 4

[Dan M]

Also see bug 197919, which suggests Mozilla make click handlers subject to popup
protection. That too would solve this problem, for now.

Comment 5

[Dan M]

The click handler pseudo-popup practice is becoming more common (see bug 230500)
and it is annoying, I agree. I'm reversing my previous decision to invalidate
this bug.

Again, we can't simply stop opening windows in click handlers by fiat. That
wouldn't be playing nice. But perhaps we could make it an advanced preference.
Note that bug 197919 is a superset of this problem. I'm toying with a fix for
that one, so there's hope for both.

Comment 6

[Dan M]

Update: it looks like the patch to bug 197919 will be checked in. It suppresses
popup windows in (among other things) click handlers. Though it's a rather
flawed solution to the problem in this bug, I can't think of a better one. See
bug 197919 comment 32 for a small study of the benefits and injuries of that
solution.

Comment 7

[thesh_bugs]

"In the realm of off-by-default, geek-only features, the only solution
I can think of is to add another level to popup blocking: 

( ) block unrequested popup windows
(*) block all freaking new windows from user script, every one"

There are yet other ways to get around this (simply placing a layer over the
webpage with some javascript that allows you to hide it) or hovering flash ads.
These have the same effect and are equally as annoying. The only thing I could
think of is content controls that allow you to block specific scripts and allow
the user to block any event or javascript function for sites that they want (I
believe there is a bug for security profiles somewhere that would allow you to
use certain settings for one site, and other settings for other sites) - this
would allow you to block onClick events on a page-by-page basis. This is along
with the general content blocking (also another bug which I am too lazy to look
up), the ability to hide specific div's, and you are set until they come up with
some other trick (and they will). There is also the anti popup blocker scripts
(there is also a bug about that) which force you to turn off your popup blocker
unless you want the page to be blocked.

Basically my point is that there will be no good solution for your average
every-day users, and you would have to employ quite a bit for the ultra-geeks to
be able to block them.

Comment 8

[Alfonso Martinez]

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

Comment 9

[Mike Connor [:mconnor]]

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

Comment 10

[Dan]

Just as a proposal to a resolution, maybe an option to stop this type of
activity could be made. The user could add a specific page to his/her list that
would not allow this type of activity to occur on said specific page, hence
eliminating a problem with legitimate pages as pointed out.

My guess is most people who find this occurence find it in a page they visit
frequently and they would most likely add it to their own personal list of
blocked sites.

Comment 11

[Trent Waddington]

www.spacedaily.com has some nasty popup blocking avoidance.  When using FireFox
they popup a box that looks like an official FireFox dialog "wizard".

Comment 12

[Dan M]

Let's try to keep focused, please. Comment 11 has nothing to do with this bug.

Comment 13

[Greg Marks]

Here is another sample that evades Firefox (taken from AquaBid.com - two pop-ups
appear on page load):

<!-- TF 728x90 JScript VAR code -->
<center><script language=javascript><!--
document.write('<scr'+'ipt language=javascript
src="http://a.tribalfusion.com/j.ad?site=AquaBidcom&adSpace=ROS&size=728x90&type=var&requestID='+((new
Date()).getTime() % 2147483648) + Math.random()+'"></scr'+'ipt>');
//-->
</script>
<noscript>
   <a
href="http://a.tribalfusion.com/i.click?site=AquaBidcom&adSpace=ROS&size=728x90&requestID=1538837377"
target=_blank>
   <img
src="http://a.tribalfusion.com/i.ad?site=AquaBidcom&adSpace=ROS&size=728x90&requestID=1538837377"

                  width=728 height=90 border=0 alt="Click Here"></a>
</noscript>
</center>
<!-- TF 728x90 JScript VAR code -->


<!-- FASTCLICK.COM POP-UNDER CODE v1.8 for aquabid.com (12 hour) -->
<script language="javascript"><!--                                 
var dc=document; var date_ob=new Date();
dc.cookie='h2=o; path=/;';var bust=date_ob.getSeconds();
if(dc.cookie.indexOf('e=llo') <= 0 && dc.cookie.indexOf('2=o') > 0){
dc.write('<scr'+'ipt language="javascript" src="http://media.fastclick.net');
dc.write('/w/pop.cgi?sid=20257&m=2&tp=2&v=1.8&c='+bust+'"></scr'+'ipt>');
date_ob.setTime(date_ob.getTime()[phone]);
dc.cookie='he=llo; path=/; expires='+ date_ob.toGMTString();} // -->
</script>                                                          
<!-- FASTCLICK.COM POP-UNDER CODE v1.8 for aquabid.com -->

 

Comment 14

[Andre Costa]

As I posted here [https://bugzilla.mozilla.org/show_bug.cgi?id=253831#c296]
www.dilbert.com also opens a pop-up window from a.tribalfusion.com, no matter
what blocking settings I have for pop-ups and JavaScript. This pop-up window
only appears on the first time I enter the site for a given Firefox session (as
long as I don't restart the browser, successive attempts on www.dilbert.com
don't trigger the pop-up window).

Comment 15

[Kevin Brosnan]

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

Comment 16

[Phil Ringnalda (:philor)]

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

Comment 17

[Jo Hermans]

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

Comment 18

[Jo Hermans]

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

Comment 19

[Kevin Brosnan]

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

Comment 20

[Kevin Brosnan]

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

Comment 21

[Phil Ringnalda (:philor)]

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

Comment 22

[Phil Ringnalda (:philor)]

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

Comment 23

[Robert Harvey]

I'd like to give another example of a site that can bypass the pop-up blocker.

http://www.comics.com/comics/janesworld/ causes a pop-up.  The "prevented a popup" strip appears, but I also get a separate window for
http://a.tribalfusion.com/p.media/RQILMIMKFJEXNTTPOIYNPGIHTFPXPISVIEJFIMVHJFCEKBSQNERKLOGWSFMLPIIKKHRCSLQSLJKSPTK/581936/pop.html
which contains a single (stupid, irritating, childish, annoying) flash animation and a 1x1 gif which I imagine is for tracking purposes.

Comment 27

[Shannon Jacobs]

Not certain if this is the same thing, but I suspect so. The top of the bug report should include some way to test or assess it. However, this bug report seemed to be the best candidate I could find.

I can definitely say that my Firefox is set to block popups on all of my computers, but this ad.yieldmanager.com website is managing to trigger popups in some way. Below is the source of one of the typical new browser windows that is popped up, but I have not been able to identify how it is being done in the source of the webpages where it is triggered. 

It is not consistent every time, but http://shanenj.tripod.com/search.html is a page that I visit that frequently shows the misbehavior. There is a delay before the popup appears, but I didn't think it was related to a link, but rather to a delay, a mouseover event, or possibly to form submission. Or perhaps they are mixing it up to try to hide the triggers?

I can confirm seeing on both Ubuntu Linux and Windows XP, and in Firefox 1.5 and 2.

<html><head><title>New offer!</title></head><body style="margin-left: 0%; margin-right: 0%; margin-top: 0%; margin-bottom: 0%"><script type="text/javascript">if (window.rm_crex_data) {rm_crex_data.push(240084);}
</script><a target="_blank" href="http://ad.yieldmanager.com/click,YSAAAAlTAgDUqQMAvHABAAAA.AEAAP8A.wD..wAIAAIi.AEAUzABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH6MvkUAAAAA,,http%3A%2F%2Fshanenj%2Etripod%2Ecom%2Fsearch0%2Ehtml,"><img border="0" alt=""height="300" width="720" src="http://content.yieldmanager.edgesuite.net/atoms/20/6c/206c17fefe4aa4f94cad5f65b8d39799.gif"></a></body></html>

Comment 28

[Shannon Jacobs]

Still not certain if I'm trying to report the same thing as this bug, but I studied it some more, and right now I think the behavior I'm trying to report is linked to *ANY* click in the webpage as a trigger for the should-be-blocked popup window. Watching closely, it appears that the aggressive scum at yieldmanager.com are somehow downloading and storing the ad somewhere during the preparation of the original page (making that page much more slow, too), and then triggering it.

You'd think they'd have learned from the bankruptcy fate of those bastards at X10. I feel like the real solution is to organize boycotts of any company that advertises too aggressively...

Comment 29

[Shannon Jacobs]

Having read many more of the comments in this thread, I feel like I should retract the previous comment as too hasty--it is clear that I am talking about the same thing. What I want to do as the solution is have a convenient option to mark sites like yieldmanager.com as 127.0.0.1, thereby consigning them to limbo.

Comment 30

[Jen]

Having read all the comments in this bug report...and see no action... I would just like to state that IE7 handles this problem without allowing the popup window to occur.  So it is possible.

Comment 31

[Raqeeb]

I'll try to fix this bug.