Closed Bug 506172 Opened 15 years ago Closed 12 years ago

going to malware site with redirect causes info bar to disappear


(Toolkit :: Safe Browsing, defect)

Not set



Firefox 16
Tracking Status
firefox14 - affected
firefox15 - verified
firefox16 --- verified
firefox-esr10 15+ wontfix
status1.9.1 --- wanted


(Reporter: samuel.sidler+old, Assigned: jaws)



(Keywords: sec-low, Whiteboard: [sg:low][advisory-tracking-])


(1 file)

(These steps may not last if the site gets fixed...)

  1. Go to
  2. "Ignore this warning"

Info bar appears and disappears as the site redirects to

Info bar stays put throughout my browsing on since it's a malware site.

Note that if I refresh the malware warning appears and if I click through it, the info bar remains. This seems to be only because redirects to

Chrome (current version) redirects to but then shows the warning page again. I don't think they have an info bar at all.
I don't think this needs to be a closed bug; it's not really a security risk, IMO. is where we do the page load and pass along LOAD_FLAGS_BYPASS_CLASSIFIER - somehow that's also being passed along with the page redirect.
(In reply to comment #1)
> I don't think this needs to be a closed bug; it's not really a security risk,
> IMO.

As I told beltzner in person, it potentially since depending on how the redirect is done. If a malware creator can do the redirect using an htaccess file, they already have access to the server so it wouldn't be hard to do. If it's using a DNS redirect, sure. Maybe it's not a major security issue and we can open it, but wiser minds than mine can make that call.

But the most important question here: Does this mean we can no longer order lunch from Una Mas?
Confirming for Firefox 3.0.x as well. Firefox 2 had a different UI for phishing sites and this bug does not apply.

I don't think we want to re-vet the URL at each redirect once the user has already said to "ignore" (which maybe Chrome is based on your description). That just forces the user to repeatedly stomp on the ignore link and get ticked off at us. The problem is just that we're losing the warning bar along the way, but I don't think there's any real security problem since the user has already been warned for that load and explicitly ignored it.

If the user hasn't hit the ignore button then we should be checking each redirect and will put up the block page if we need to.
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x-
Group: core-security
Whiteboard: [sg:low]
I don't know how much this is related to phishing protection but this also happens sometimes on yahoo mail if viewed with js disabled and on IP Boards, when doing a search from index.php?act=Search&CODE=01 I should get the see bar to allow the redirect to index.php?act=Search&CODE=show&searchid=<ID>&<OTHER_VARS>. First attempt it just closes itself in a split second, second attempt (after waiting for the forum's anti-spam counter to finish) it stays.

FX 3.5.3 on Win 7 RC x64.
Had my anti-phising on etc. Was not given a choice to ignore, but given no option as I was automatically directed to the My Space site which I don't even use, then would completely freeze up.
Assignee: nobody → fryn
After discussing this with :MattN, it seems that, in (DoURILoad), aBypassClassifier needs to be set to false for redirects.

If I'm understanding this correctly, it makes more sense to make the fix there rather than in the front-end. Am I correct in this assessment? If so, I'm not the best person to fix docshell stuff, but I can give it a try if someone can give me pointers.
OS: Mac OS X → All
Version: 3.5 Branch → Trunk
Frank and I chatted about this a couple weeks ago, and came up with what should be a simpler solution. (At least, it sure avoids docshell :).

Notification bars already support .persistence and .timeout properties, which are used by login manager for exactly the problem described here. [Sometimes when you log in to a site -- Google being one huge example -- there can be a number of redirects between clicking the "login" button and ending up at your final destination. Having the "Remember Password?" notification disappear before you have a chance to see if it's successful was why these properties got implemented.]

Same solution should work here. If the user continues on to the malware site, use the timeout to make sure the notification bar remains for X seconds. This will persist across redirects during that time period. There's a slight quirk in that if you click a link during that period, the bar will also remain. But let's call that a feature -- if you're clicking a link on a malware site and a warning remains, it's quite likely still relevant (since malware sites often try to trap you in a web of malware/spam/phishing links).

We could handle _typing_ a URL as a special case, and immediately clear any existing malware notification before loading the new URL. Fine by me without with or without.

Basic idea here is that since we're already in sketchy territory (malware site, user explicitly continues through warning), having an imperfect-but-simple solution is better than nothing. Especially when the imperfection is biased toward showing the notification longer than it maybe really should.
Easy STR:

1) Load "" (note: no "www")
2) Click "ignore this warning"
3) Page loads and redirects to (with "www")

At step 3, the warning bar flashes into view and then disappears.
Most of us probably moved on to bigger and better things, like FX13 right now. This bug was important to be fixed when the browser was in popular use. Now it's not so much of an issue... FX13 doesn't load any bar, it just redirects to "www". Spending development resources on a minor use project is a waste.
Attached patch PatchSplinter Review
I talked with Frank and he said he was cool with me taking this bug.

This patch sets persistence = -1 on the notification bar so it will remain visible until the user removes it explicitly.

I tested it out with the STR in comment #8 and it worked as desired.
Assignee: fryn → jaws
Attachment #638956 - Flags: review?(dolske)
Attachment #638956 - Flags: review?(mnoorenberghe+bmo)
Comment on attachment 638956 [details] [diff] [review]

Review of attachment 638956 [details] [diff] [review]:

This seems straightforward and I think the quirk mentioned in comment 7 is acceptable for this case.
Attachment #638956 - Flags: review?(mnoorenberghe+bmo)
Attachment #638956 - Flags: review?(dolske)
Attachment #638956 - Flags: review+
Flags: in-testsuite-
Target Milestone: --- → Firefox 16
Comment on attachment 638956 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): no bug #
User impact if declined: users may not see critical warning bar if malware site uses a redirect
Testing completed (on m-c, etc.): locally, just landed on m-i
Risk to taking this patch (and alternatives if risky): none expected, standard way to make notification bars persistent
String or UUID changes made by this patch: none

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: chance that users wont see a security warning
Fix Landed on Version: fx16
Risk to taking this patch (and alternatives if risky): none expected
String or UUID changes made by this patch: none

See for more info.
Attachment #638956 - Flags: approval-mozilla-esr10?
Attachment #638956 - Flags: approval-mozilla-aurora?
Attachment #638956 - Flags: approval-mozilla-beta?
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 638956 [details] [diff] [review]

Taking a lingering sg:low in our final beta isn't worth non-zero risk. Let's get this on 15 and the corresponding ESR after the version bump.
Attachment #638956 - Flags: approval-mozilla-beta?
Attachment #638956 - Flags: approval-mozilla-beta-
Attachment #638956 - Flags: approval-mozilla-aurora?
Attachment #638956 - Flags: approval-mozilla-aurora+
This is a longstanding low-severity bug, I don't think we need to take it on ESR.
Comment on attachment 638956 [details] [diff] [review]

Agree with Gavin, this doesn't fit in ESR criteria so no need to take it.
Attachment #638956 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10-
(In reply to Justin Dolske [:Dolske] from comment #8)
> Easy STR:
> 1) Load "" (note: no "www")
> 2) Click "ignore this warning"
> 3) Page loads and redirects to (with "www")
> At step 3, the warning bar flashes into view and then disappears.

The warning bar remains on the screen.
Verified fixed on FF 15b3 on Win 7/64, Ubuntu 12.04 and Mac OS X 10.6.
Whiteboard: [sg:low] → [sg:low][advisory-tracking-]
Verified fixed on FF 16b1 on Win 7/64, Ubuntu 12.04 and Mac OS X 10.6.
QA Contact: paul.silaghi
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.