Closed Bug 329746 Opened 14 years ago Closed 14 years ago

Content injection spoofing with a space before colon in HTTP header


(Core :: Networking: HTTP, defect, P1, critical)






(Reporter: kohei, Assigned: darin.moz)



(Keywords: fixed1.8.1, testcase, verified1.8.0.4, Whiteboard: [sg:high])


(6 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20060111 Firefox/
Build Identifier: N/A

Note: This bug was originally reported to IPA (Information-technology Promotion Agency, Japan) and forwarded to us at Mozilla Japan. I'm NOT original reporter. Don't mention my name in the security advisory. For more information about IPA, visit 


Attackers can forge a Web page on another domain by sending the HTTP response including Transfer-Encoding header with a space between header name and colon (:). This could be used for the real phishing to steal sensitive data, such as user password or cookies. 

Windows XP Professional SP2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060129 Firefox/1.6a1

Reproducible: Sometimes

Steps to Reproduce:
1. Set up Firefox to use Microsoft Internet Security & Acceleration Server 2004 (ISA Server) for HTTP proxy
2. Provide the proxy with HTTP response with the following conditions:
 A. "Content-Length" header is included
 B. "Transfer-Encoding : chunked" is included (note a space between "Encoding" and ":")
 C. response length with chunk size data of B is shorter than the value of A

Actual Results:  
"Transfer-Encoding SP" header (Transfer-Encoding header with a space) is not defined by HTTP/1.1. Therefore, ISA Server will send data of the number of bytes specified by Content-Length header to the browser. Transfer-Encoding header with a space will be transferred as is. This is appropriate behavior compliant with HTTP/1.1.

Received the response via proxy, Firefox recognizes "Transfer-Encoding SP" header as "Transfer-Encoding" header and understands that the response body is chunked encoded.

The rest of response determined by the condition C is incorrectly recognized as the response of following HTTP request.

Expected Results:  
The rest of response should not be recognized as the response of following HTTP request.

The malicious Web site admins can target Firefox users who use HTT/1.1 proxy to steal cookies or build web pages including fake login form for arbitrary domains.

Workaround: Don't use ISA Server

More info coming.
I found Bug 80313. Is this a mistake on the implementation?
Attached image data flow chart
IPA send us the data flow chart. I attach it.
Attached image data flow chart 2
Here is another chart. 
This bug can also be reproduced with Content-Length header.
Nominate for blocking.
Flags: blocking1.8.1?
Flags: blocking1.8.0.2?
-> me, for investigation
Assignee: nobody → darin
Ever confirmed: true
Flags: blocking1.9a1+
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.2?
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
Any updates?
Priority: -- → P1
Target Milestone: --- → mozilla1.8.1
I don't think spaces around the colon have anything to do with this problem.  Firefox prefers the last Content-Length header over the first, and it will prefer "Tranfer-Encoding: chunked" over a given Content-Length.
OK, nevermind.  I understand now.  This problem occurs because Firefox tolerates headers that are malformed.  ISA proxy on the other hand, ignores the malformed headers, and therefore this bug gets introduced.  I recall that we added support for sloppy header parsing for consistency with IE because many websites serve malformed headers.  Some, even send '=' instead of ':'.  I'm not sure how to proceed.  If we make Firefox conform strictly to RFC 2616, then we risk breaking web site compatibility.  If we do not, then we risk security.
Here's the code that Firefox uses to parse response headers:

The comment documents the parsing rules that we implement.
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Whiteboard: [sg:high]
The patch for this bug will conflict with the patch for bug 328817, so I'm making this bug depend on that bug.
Depends on: 328817
I have IE, version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519, and it does not appear to be vulnerable to this problem.  It seems like Microsoft must have tightened up the header parsing in IE somewhere along the way, or maybe ruslan was wrong:

It seems that the best fix might be to make our header parsing strict again given the ubiquity of IE 6.
Attached patch v1 patchSplinter Review
Attachment #217369 - Flags: superreview?(bzbarsky)
Attachment #217369 - Flags: review?(cbiesinger)
Safari also implements strict header parsing from what I can tell.
Attachment #217369 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 217369 [details] [diff] [review]
v1 patch

the table and nsHttp::IsValidToken were just moved without changes, right?
Attachment #217369 - Flags: review?(cbiesinger) → review+
> the table and nsHttp::IsValidToken were just moved without changes, right?

Closed: 14 years ago
Resolution: --- → FIXED
Attachment #217369 - Flags: approval1.8.0.3?
Attachment #217369 - Flags: approval-branch-1.8.1?(bzbarsky)
Attachment #217369 - Flags: approval-branch-1.8.1?(bzbarsky) → approval-branch-1.8.1+
Keywords: fixed1.8.1
Comment on attachment 217369 [details] [diff] [review]
v1 patch

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #217369 - Flags: approval1.8.0.3? → approval1.8.0.3+
Keywords: fixed1.8.0.3
v.fixed on 1.8.0 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv: Gecko/20060420 Firefox/, no "hacked" popups with either of Darin's testcases, the second headers sent are not processed.
Keywords: testcase
Whiteboard: [sg:high] → [sg:high] coordinate advisory release with IPA
IPA have confirmed that this vulnerability affects Firefox only.
It's OK to publish security advisory as of Firefox Thanks!
Whiteboard: [sg:high] coordinate advisory release with IPA → [sg:high]
IPA told us that the original reporter is Kazuho Oku (Cybozu Labs).

dveditz: Please mention his name in the upcoming advisory.
Group: security
Attached patch 1.0.x patchSplinter Review
proposed backport
Attachment #225476 - Flags: review?(caillon)
You need to log in before you can comment on or make changes to this bug.