580168 - HTTP Authorization header sent for entire domain rather than specific URI

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[Reed Loden [:reed]]

Bartosz /zynzel/ Kupidura (iforone [at] spof.pl) reported the following issue to security@:

============================================================================

I have found a bug in the Mozilla Firefox - after proper authentication
(basic/digest http auth), the web browser sends a 'Authorization' header to
every
site which sends us 'WWW-Authenticate' header on a given domain. Only
thing that we should know is a realm, which is not a secret.

The bug can be used, when many people have an access to place where the
scripts are in one domain (for example mod_usedir in Apache web server).

Firefox ignores 'depth of link', sends 'Authorization' even when the 'bad'
htaccess is located above the 'good' (see PoC) 
[ RFC 2617 ]

2 Basic Authentication Scheme

[...]

A client 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. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.

[...]


The scheme of an attack:
1. The victim autenticates on the site, where we want to steal the
credentials
2. Deliver to victim a link to the our site in the attacked domain
3. Steal the header 'Authorization'

PoC:
http://iforone.spof.pl/a/a/
http://iforone.spof.pl/b/

003307:spof.pl% cat public_html/a/a/index.php 
<?php
if (!isset($_SERVER['PHP_AUTH_USER'])) {
    header('WWW-Authenticate: Basic realm="Realm"');
    header('HTTP/1.0 401 Unauthorized');
} else 
    echo "Hello ".$_SERVER['PHP_AUTH_USER']."/".$_SERVER['PHP_AUTH_PW'];
?>
003313:spof.pl% cat public_html/b/index.php
<?php
if (!isset($_SERVER['PHP_AUTH_USER']))
    header('WWW-Authenticate: Basic Realm="Realm"');
else
    echo $_SERVER['PHP_AUTH_USER']."/".$_SERVER['PHP_AUTH_PW'];
?>


The solution of this problem is to check whole URI, not only domain.

=============================================================================

Comment 1

[Reed Loden [:reed]]

Posted to full-disclosure by reporter (http://seclists.org/fulldisclosure/2010/Sep/320). Unhiding.

Comment 2

[Johnny Stenback (:jst)]

Not blocking 2.0.

Comment 3

[Justin Dolske [:Dolske]]

I think we should WONTFIX this, I suspect no browser has ever implemented the RFC that way and doing so would likely break sites.

I just tested loading with our intranet Wiki (which uses HTTP Auth)...

1) load https://intranet.mozilla.org/All_hands/4Q2010
2) authenticate
3) load either https://intranet.mozilla.org/Hiring/FirefoxEngineer or
   just https://intranet.mozilla.org

All of Firefox 4, Chrome, and IE 9 behaved the same way. None prompted for authentication at step 3, which is what seems to be asked for here.

The only thing that _might_ make sense to do is to not automatically send the user's credentials to another path of the side until we've seen that it has requested them with the current realm.

This normally wouldn't be a useful defense (since the realm is generally not considered sensitive info), but if a site _did_ want to treat the realm that way (by adding some kind of secret value to the realm), you could possibly make the client more robust to this kind of attack. The tricky bit would be keeping that magic value secret -- you'd probably need to pre-establish a shared secret with a cookie.

For example:

0) client/server have previous relationship, client has cookie = encrypt(secret,goodkey).
...
1) client requests site.com/good/path (with cookie, but no creds)
2) server computes decrypt(cookie, key1), responds with HTTP 401 with realm = |"Hello" + secret|
3) client requests site.com/good/path + credentials
...
4) client requests site.com/alsogood/path (with cookie, but NO creds)
5) server responds with same realm as step 2
6) client requests site.com/alsogood/path + credentials
...
7) client requests site.com/evil/path (with cookie, but NO creds)
8) server code for this path isn't able to compute decrypt(cookie, key1), so
   can't respond with same realm as step 2/5.
9) user agent prompts user for credentials
...
10) user ends same credentials anyway, because they don't understand how site.com/good and site.com/evil can be different. :-/

But this would be a pretty big change, and would need some significant security review (more than the off-the-cuff thought I just gave it, for sure!).

In the end, I suspect it's just not worth it as HTTP auth is seldom used. Better to just change the spec to match reality (+ a note of this attack), and move on to better authentication schemes. Especially since most users would just do what step 10 says anyway...

Comment 4

[u408661]

The more I look at this, the more I'm inclined to agree with Justin. Basic auth doesn't tend to be used for really sensitive places, and the places where basic auth IS used tend to be designed in such a way that the broken behavior that fx, chrome, and ie exhibit is actually "The Right Thing To Do" (or, at least, what the site designers expect to happen).

Of course, whether or not this is ACTUALLY the right thing is another question, but I'm in favor of not breaking existing behavior that both site designers and users expect unless there's a SERIOUS security risk involved.

Comment 5

[Jason Duell]

I agree with comments 3 + 4.