Closed Bug 381264 Opened 17 years ago Closed 17 years ago

XHR TRACK method (IIS) could be used to compromise Authorization and Cookie headers

Categories

(Core :: XML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: beisenmann, Assigned: dveditz)

Details

(Keywords: fixed1.8.0.13, fixed1.8.1.5, privacy, Whiteboard: [sg:low])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Firefox still allows XMLHTTP to use the TRACK method.  This vulnerability can be used almost exactly as Bug 302489 by attackers and will reveal HTTP Authorization and Cookie headers.  The code to reproduce only differs with the HTTP method used.



Reproducible: Always

Steps to Reproduce:
1. Have the following code execute on a page served from a server that supports the TRACE Method

xmlhttp = new XMLHttpRequest();
 xmlhttp.open("TRACK", "a.html");
 xmlhttp.setRequestHeader("Max-Forwards", "0");
 xmlhttp.onreadystatechange=function() {
 if (xmlhttp.readyState==4) {
  alert("Status: " + xmlhttp.status + "\n" + xmlhttp.responseText)
 }
 }
 xmlhttp.send(null)
}
Actual Results:  
The server will respond with an echo of the response readable by javascript in the responseText including Cookies and HTTP Auth.  This would aldo bypass the httpOnly cookie flag.


Apply the following patch to nsXMLHttpRequest.cpp

915a916,920
>
>   // Disallow HTTP/1.1 TRACK method (see bug XXXXXX).
>   if (method.LowerCaseEqualsASCII("track")) {
>     return NS_ERROR_INVALID_ARG;
>   }
Assignee: nobody → xml
Component: Security → XML
Product: Firefox → Core
QA Contact: firefox → ashshbhatt
Er... HTTP doesn't specify a track method, and apache doesn't seem to implement it.

What server did you try this with?
OS: Windows XP → All
Hardware: PC → All
It appears to be a Microsoft thing: an unlogged TRACE (why?)
http://archives.neohapsis.com/archives/ntbugtraq/2003-q4/0321.html
http://msdn2.microsoft.com/en-us/library/aa364664.aspx

It's only purpose seemed to be to have an unlogged TRACE, and the "unlogged-ness" of it was a problem for server admins. In IIS 6 it's just a TRACE. Looks like recommended practice to block it on the server side:

http://msmvps.com/blogs/bernard/archive/2003/12.aspx

I guess we should block this one too. Jonas, can we get this into the WebAPI WG XHR spec, or is it too late for that?
Assignee: xml → dveditz
Severity: critical → normal
Status: UNCONFIRMED → NEW
Component: XML → Networking
Ever confirmed: true
Summary: XMLHTTP TRACK method could be used to compromise Authorization and Cookie headers → XHR+TRACK method (IIS) could be used to compromise Authorization and Cookie headers
(In reply to comment #1)
> Er... HTTP doesn't specify a track method, and apache doesn't seem to implement
> it.
> 
> What server did you try this with?
> 

Microsoft IIS. I dont believe its enabled by default on IIS 6.0 however earlier versions did enable it by default. http://www.kb.cert.org/vuls/id/288308
Severity: normal → critical
Component: Networking → XML
Summary: XHR+TRACK method (IIS) could be used to compromise Authorization and Cookie headers → XMLHTTP TRACK method could be used to compromise Authorization and Cookie headers
Attached patch add "track"Splinter Review
Attachment #265438 - Flags: review?(cbiesinger)
If MS has fixed their servers in 2004 and it's non-standard to begin with perhaps we shouldn't bother. On the other hand it's a trivial change to help protect our users from clueless server admins.
Assignee: dveditz → xml
Severity: critical → normal
Summary: XMLHTTP TRACK method could be used to compromise Authorization and Cookie headers → XHR TRACK method (IIS) could be used to compromise Authorization and Cookie headers
Attachment #265438 - Flags: review?(cbiesinger) → review+
Does this bug need to remain security sensitive? The TRACE issue was announced, and the fact that IIS servers implement TRACK is likewise old news.
Assignee: xml → dveditz
Keywords: privacy
Whiteboard: [sg:low]
Comment on attachment 265438 [details] [diff] [review]
add "track"

I guess since XHR got moved to content I need module-owner/peer approval as well.
Attachment #265438 - Flags: superreview?(jonas)
Attachment #265438 - Flags: approval1.8.1.5?
Attachment #265438 - Flags: approval1.8.0.13?
Is this exploit public for other browsers? If not we probably don't want to publish it on the webapi mailing list without giving the other vendors an opportunity to release a patched version first
Attachment #265438 - Flags: superreview?(jonas) → superreview+
Its been well known for quite a while now.  Microsoft created a patch to prevent XHR from using the TRACE and TRACK methods around a year ago for IE6.  I have no specific information about Opera.
Comment on attachment 265438 [details] [diff] [review]
add "track"

approved for 1.8.1.5 and 1.8.0.13, a=dveditz for release-drivers
Attachment #265438 - Flags: approval1.8.1.5?
Attachment #265438 - Flags: approval1.8.1.5+
Attachment #265438 - Flags: approval1.8.0.13?
Attachment #265438 - Flags: approval1.8.0.13+
Fix checked into trunk
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13+
Checked into 1.8 branches
Group: security
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.