Open Bug 243572 Opened 21 years ago Updated 2 years ago

Annoying confirm dialog on every request to site when using a user:password URL

Categories

(Core :: Networking: HTTP, enhancement, P5)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows 2000
Type:
enhancement

Tracking

()

People

(Reporter: ken2006, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: "Suspicious auth". See bug 248945 for defensive auth [necko-would-take]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040512
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040512

A confirm dialog repeatedly pops-up even after selecting 'OK', warning that "You
are about to logon to the site "www.somesite.com" with the username "ken" but
the site does not require authentication. This may be an attempt to trick you."

Reproducible: Always
Steps to Reproduce:
1. Load to a URL that does not requires www-authenicate.
2. Warning pops-up, confirm (OK).
3. Click another link - re-occurs.



Expected Results:  
Either remember that OK was selected, or do not present this dialog if the
connection was established from a bookmark (only when users clicks on a link
from a site). Many servers dont send authenticate headers after an initial
login, since they maintain login state by session cookie/URL - so will never
subsequently send a www-auth challenge (while user logged in). Moreover, some
users like to bookmark VERY frequently used sites with the crendentials - but
some paths on the sites do not immediately require authentication - then the
pupose of storing the crendentials is to preemtively make them available if a
restricted URL is later entered. For this reason, one possible idea of
'clearing' the URLs credentials if not auth is required, would not work.
I actually just verified that this new behavior may not even be neccesary..
watching the header exchange, even when I choose 'OK' on the dialog, no
authenticate data is sent ot the server anyway, enless and until after the
server first sends a 401-auth response. So at least the dialog stating "even
though the server doesnt require auth" is accurate - but the part about "about
to login" is not.

This header behavior has already been the expected behavior - browsers should
only send an "Authorization:" response when challenged, and Mozilla has always
done that to my knowledge.

Perhaps this alert should only apear when clicking on a foreign site's link AND
the target site also issues a challenge, which is the only time (that I know)
Mozilla would send any kind of Login information anyway.

The feature has definate security value though, glad to see people are making
this software more and more safe. Mozilla rocks.
The idea here is to tell you (as a user who knows nothing about usernames in
URLs) that a url like http://www.mozilla.org@foosite.com/ is not what it looks
like...  
Yes, we expected that this might annoy some users, and you bring up an
interesting scenario in which this prompting is particularly annoying.

You may appreciate knowing that you can effectively disable this "feature" by
adjusting this hidden user preference:

  network.http.phishy-userpass-length

Just load about:config, right click and choose New->Integer.  Enter this pref
name and set the numeric value to some large number.
Thats a great point!!! I've seen lots of that junk mail mental midget stuff
going around... So perhps the dialog can be supressed enless click on a link
thats not trusted, and then also after the first click into the site. This would
solve the recurrence of the alert when:

-User already acknowledged the alert and desires to continue clicking through
links on the site with same credentials (since subsequent relative (host-less)
links inherit the URL-bars crendentials, thus invoking the alert)
-User uses bookmarks with user:pass syntax to premptively provide crendentials.
Thank you Darin, I forgot to mention that I didnt see the preference for
disabling it - but disabling altogether would diminish its clear value - so
perhaps the preference setting *should not* be included - theres too many users
who dont understand the bad potential of disabling it. I'd propose to show the
dialog always, except when outside the sandbox (bookmarks). The feaure has real
merit.
PS by "perhaps the preference setting *should not* be included", I meant not
included in the Edit-Prefences dialog, where layman users (or even nieve
sysadmins in corp environments) could disable it. The about:config method is
fine IMO.
Right, we have no intentions of surfacing this preference in the UI!

I agree that we could remember the fact that the user acknowledged this dialog
per domain per session.  That would not be hard to implement.  We already store
authentication data per domain per session, so this is just an additional 'bit'
to remember.

-> me

dveditz, asa, bz: what do you guys think?  do you agree with this approach?

also, it may be more difficult to sandbox bookmarks.  i agree that that is worth
doing, but it may be more complicated to implement.
Assignee: security-bugs → darin
Status: UNCONFIRMED → NEW
Component: Security: General → Networking: HTTP
Ever confirmed: true
I sure hope a patch for this can get in before the release version - I spent
part of my day trying to get the "network.http.phishy-userpass-length" setting
to stay persistent - it wouldnt get dropped into my prefs.js file for some
reason when added from about:config, so after a restart the pop-up kept nagging
me - even after manually adding to prefs.js, same thing. Finally discovered that
(apparently) the param has to be put into user.js.

user_pref("network.http.phishy-userpass-length", 1024);

If this goes unpatched into the 1.7 release, its almost certain to be the
biggest single complaint, sorry to say. It drove me nuts.
*** Bug 260989 has been marked as a duplicate of this bug. ***
dupe of bug 248945 ?
I know this one is older, but the other one has already votes.
On re-reading the two this bug appears to be wanting to suppress the "suspicious
auth" dialog (site doesn't actually require auth, yet), whereas bug 248945
covers the "defensive auth" check.
Severity: normal → enhancement
HUH ? i dont see this as an enhancement
if i visit a site, aknowledge i want to use it with login info.
WHY is it an enhancement when mozilla keeps asking me wether it should login tho
i navigate on the same site ???
Perhaps Moz needs to remember the decision for each auth:url, on a per session
basis.

It was also mentioned that a preference to disable this 'feature' might be added
but I havent noticed it, at least in FF (made the move 3 months ago :-).
bug 248945 covers the case of sites that really require auth. The dialog in this
bug is the "Suspicious Auth" dialog that comes up when the URL contains auth but
the site doesn't request it. This is a sure-fire sign of phishing (fake auth
like http://www.yourbank.com:blahblah@hacker.com) which is why we warn. Refining
this behavior (remembering that site was warned in this session already, or a
permanent per-site suppression) is the very definition of an enhancement. This
is not a value judgement that it's not important, I personally strongly object
to the enhancement/bug distinction being lumped in with the bug severity field
since that implies enhancements are never serious.

I'm basing this on Ken's initial comment 0. If this really is about the
"defensive" auth then it's a straight-up dupe of bug 248945. Since Darin owns
both and we've asked about dupes before (comment 10, bug 248945 comment 5) he
must think this is the other dialog too.
Depends on: 248945
Whiteboard: "Suspicious auth". See bug 248945 for defensive auth
*** Bug 248945 has been marked as a duplicate of this bug. ***
I duped the other bug to this one.  It's the same can of worms really.  I may
not have time to implement a fix for this bug in time for Firefox 1.1 (and other
Gecko 1.8 based products), so help would definitely be appreciated.
Keywords: helpwanted
Priority: -- → P4
Target Milestone: --- → mozilla1.8beta2
*** Bug 227414 has been marked as a duplicate of this bug. ***
*** Bug 278876 has been marked as a duplicate of this bug. ***
*** Bug 276018 has been marked as a duplicate of this bug. ***
*** Bug 291734 has been marked as a duplicate of this bug. ***
*** Bug 302822 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.8beta2 → mozilla1.8beta5
Flags: blocking1.8rc1?
Flags: blocking1.8rc1? → blocking1.8rc1-
Target Milestone: mozilla1.8beta5 → mozilla1.9alpha
Assignee: darin → nobody
QA Contact: networking.http
Target Milestone: mozilla1.9alpha → ---
I think this feature should have an option to be disabled on a PER-SITE basis, via a (hidden) pref. Just as it is done with NTLM auth.
I agree with Johan, it would be specially useful to whitelist intranet addresses.
Whiteboard: "Suspicious auth". See bug 248945 for defensive auth → "Suspicious auth". See bug 248945 for defensive auth [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P4 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.