Too many phishing pings in FF2.0.x

RESOLVED FIXED

Status

()

Toolkit
Safe Browsing
RESOLVED FIXED
10 years ago
3 years ago

People

(Reporter: Garrett Casto, Unassigned)

Tracking

2.0 Branch
x86
Linux
Points:
---
Bug Flags:
blocking-firefox3 -
blocking1.8.1.12 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.6) Gecko/20060201 Firefox/2.0.0.6 (Ubuntu-dapper)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.6) Gecko/20060201 Firefox/2.0.0.6 (Ubuntu-dapper)

Thousands of users are pinging the phishing service significantly more than once every 30 minutes.  Some users (<100) are pinging more than 1000 times an hour.

Reproducible: Always

Comment 1

10 years ago
Does this state seem to persist at all through restarts?  Like, will the same client stop and then restart pinging too fast?
Version: unspecified → 2.0 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is for a list update, not a "check every URL" lookup? That interval is hardcoded, hard to imagine thousands of users hacking listmanager.js buried in our chrome. If it were taken from a pref I could believe a small fraction might tweak it to "be more safe".

Is old bug 115865 relevant here?

Can you tell us anything about the platforms these users are running on from their user agents? Is it all Windows? All Mac? any particular OS version?
Flags: blocking1.8.1.10?
Flags: blocking-firefox3?
(In reply to comment #0)
> Thousands of users are pinging the phishing service significantly more than
> once every 30 minutes.  Some users (<100) are pinging more than 1000 times an
> hour.
> 
> Reproducible: Always
> 

Have you verified these are really the same client and not just multiple clients you see as coming form the same IP address due either to natting or http Proxies?
(Reporter)

Comment 4

10 years ago
I'm doing this analysis by looking at server stats, not particular clients, so I don't know if any particular OS/version is causing the problem.  I also don't know if this is a function of restarts, etc.  I have never had an actual client on hand that exhibited this problem.  This analysis is based on cookies, so proxies shouldn't matter.

Comment 5

10 years ago
We should try to get the user agent strings.  Also, maybe it's a bot or a cookie value that's being set on multiple computers (e.g., a company many have a standard image that includes firefox with a cookie).  Do these users properly respond to back off behavior?
(Reporter)

Comment 6

10 years ago
Certainly it has occurred to me that these aren't actual users.  I was just to make sure that there wasn't a bug that was causing this behavior.  I can try examining user agent strings to see if anything look suspicious.
Is it not possible to distinguish between full lookups and enhanced mode checks?  We don't have enhanced mode on trunk anymore, but I could easily see 1000 pings an hour if someone's opening a lot of tabs... otherwise I have no idea what could cause this, though the new protocol should support the backoff commands.
(In reply to comment #4)
> I'm doing this analysis by looking at server stats, not particular clients, so
> I don't know if any particular OS/version is causing the problem.  I also don't
> know if this is a function of restarts, etc.  I have never had an actual client
> on hand that exhibited this problem.  This analysis is based on cookies, so
> proxies shouldn't matter.
> 
Well, actually could matter.  Depending on how the cookie is set, unless you tell the proxy not to cache the thing that sets the cookie, and unless the proxy actually pays attention, it is possible for every machine behind the proxy to end up with the exact same cookie.  If the cookie setter thing actually runs some kind of JavaScript locally that creates a random number to be used in the cookie, anything that just does a is the cookie set and if not create the cookie on the server side and then send back something to set it, could be being cached on the proxy so everyone after that just gets the same cookie.
(Reporter)

Comment 9

10 years ago
These are all full lookups, not enhanced mode requests.

Cookies are definitely set server side.  However, I'm not in charge of the server that actually sets the cookies.  I'll look into how exactly it's done.
We need to get FF2.0.0.10 out (jar: redirect xss bugs that's affecting Google among others), we can't hold the release to figure this one out. -> 2.0.0.11
Flags: blocking1.8.1.10? → blocking1.8.1.11?
Please renominate if there's more information on this, it seems incredibly unlikely to reproduce easily, given that its thousands out of tens o millions.

At the same time, if we get more info, we'll fix it...
Flags: blocking-firefox3? → blocking-firefox3-
(Reporter)

Comment 12

10 years ago
I agree, this shouldn't hold anything up until we can conclusively figure out if something is wrong.  I'll try and readdress this when I get more time, but unfortunately I'm a little swamped at the moment.
Could this be caused by an issue on the client side such as no write access to the url classifier database?
Not enough known to block a security release, but if this gets figured out let us know (assigning to a real person would be a good start).
Flags: blocking1.8.1.12? → blocking1.8.1.12-

Comment 15

6 years ago
Is this still a problem nowadays or can this report be closed as obsolete?

Comment 16

6 years ago
This hasn't been a problem since 3.0.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

3 years ago
Component: Phishing Protection → Phishing Protection
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.