Open Bug 707156 Opened 13 years ago Updated 2 years ago

HTTP basic auth: wrong credentials sent when navigating between sibling URLs using different realms

Categories

(Core :: Networking: HTTP, defect, P3)

10 Branch
x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: pae9, Unassigned)

References

Details

(Whiteboard: [necko-backlog])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 2011092200

Steps to reproduce:

If I log into area A and provided my credentials. Then I went to a page in area B with different credentials. Then I went back to a page in area A. 



Actual results:

Although all of the pages loaded OK, when I went back to area A after viewing area B, the error log on my apache server received new entries of the form:

"access to <some page> reason: user 'AREAB' does not meet 'requirements for user/valid-user to be allowed access"

Where <some page> is a page in area A, but the user is the user for area B. i.e., although the page managed to load, Firefox clearly tried to use the credentials for area B at some point, even though it is looking for a page in area A. I tried the same process in another browser, and no errors appeared in the apache log, hence I think it's a Firefox issue.


Expected results:

The pages should have loaded without generating apache errors, i.e. when accessing area A for the second time, Firefox should have sent only the area A credentials.
Firefox isn't sending credentials - rather it is sending cookies. If the site uses the same cookie for the different sections, this is the expected result.

TE?
Phil -> Please provide a public URL or reduced test case that exhibits this issue.
Tim,
I can't provide a public URL for this unfortunately. 
However I can provide a simple reduced test case.

Create a basic apache config with areas thus: 

<Directory "/some/path/areaa">
        Order allow,deny
        Allow from all
        AuthType Basic
        AuthName "Some test area"
        AuthUserFile /path/to/users_file
        Require user ThisUser
</Directory>

<Directory "/some/path/areab">
        Order allow,deny
        Allow from all
        AuthType Basic
        AuthName "Another secure area"
        AuthUserFile /path/to/users_file
        Require user DifferentUser
</Directory>

Then in firefox, load the URL for "areab" and log in as "DifferentUser".
All OK.

Now go to "areaa" in the browser and log in as "ThisUser". Also OK.

Now go back to "areab"
Although the page loads, I get the following in the apache error log:

"access to /areab failed, reason: user 'ThisUser' does not meet 'require'ments for user/valid-user to be allowed access"

Curiously, on Firefox 7.0 (packaged for OpenSuse 11.4), after doing
this, if I hit reload on area B, nothing gets added to the error log.
However on Firefox 10.0 (from the Ubuntu firefox-next ppa), every time I hit reload, a new entry identical to that above appears in the error log. 

Hope this helps.
Component: General → Untriaged
QA Contact: general → untriaged
Version: 7 Branch → 10 Branch
I didn't find an exact duplicate, but this seems similar to bug 515651, which is about navigating from http://host/pathA ->  http://host/pathB -> http://host/pathC (all having different realms) and getting pathA's credentials submitted to pathC.

It mentions RFC 2617 ("clients should assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge."), but I'm unsure if that applies in your scenarion (areaB->areeA->areaB) or if the previously observed realm for areaB must be taken into consideration when picking the credentials to send.
Blocks: 61681
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
QA Contact: untriaged → networking.http
Summary: Firefox appears to be transmitting multiple credentials → HTTP basic auth: wrong credentials sent when navigating between sibling URLs using different realms
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
I believe I am the initial reporter of this class of problems (bug 137852, 17 years ago) and can confirm a variation of this problem still exists using the Apache configuration listed in comment 3, but with different specifics.

Firstly, this is working for me, assuming:
 /areaA is RealmA with userA/passA
 /areaB is RealmB with userB/passB

Authenticating as userA/RealmA at /areaA, works ok.
Authenticating as userB/RealmB at /areaB, works ok.
I can now surf /areaA and /areaB freely (both simply show the directory index)

Here is the problem:
Authenticate as userB/RealmA at /areaA, fails ok.
Authenticate as userA/RealmA at /areaA, works ok.
Authenticate as userA/RealmB at /areaB, fails ok.
Authenticate as userB/RealmB at /areaB, works ok.
Surfing to /areaA now prompts for credentials.

Something in Firefox Quantum 63.0.3 (64-bit, Linux) appears to be confusing realm authentication failures beyond the scope of the realm being authenticated. In all cases, the Firefox prompt to save the credentials was declined. However, it does not appear that Firefox is first sending the wrong credentials.

Regarding comment 4, the three-realm variation (areaC) also appears to work as described above.

I just experienced this, or very similar.

Logged into a website I'm developing for using basic authentication,

/areaA, RealmA as userA

then into

/areaB, RealmB as userB

Navigated back to /AreaA, did some browsing, and site appeared to time-out. I though the server had gone down, but after some investigation and help from hosting company support, it turns out my IP address was blocked due to "too many failed logins". Couldn't work out what that meant, since I hadn't experienced a "failed login".

Looking at the Apache logs, though I can see that requests for files in /areaA are being made using the userB username, returning 401, and then getting immediately re-attempted with the userA username, whereupon they succeed. This seems to happen for every file access.

This is a serious bug; I had to have my IP whitelisted just so I could use the site without being immediately re-blocked.
I'm sure other users have had this happen, and not figured out why, or how to fix it.

Please fix!

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.