Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Cross-Site Tracing (XST) security vulnerability 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If I understand how it works correctly, it goes a bit like this:

    I connect to malicious web server (or hacked friendly one)
    That web server sends me some javascript
    That javascript sends a TRACE request to some site it knows I use
    The TRACE request bounces back my cookies/credentials
    The javascript thus has access to those credentials that it didn't know how to get at before
    The malicious web server can then re-use these credentials in other attacks

    It's an interesting attack vector. I like it. One more reason n
    • I think that's a nice summary.

      #That javascript sends a TRACE request to some site it knows I use

      My only quibble is that for this attack to be useful to the person who initiates it, the TRACE must be sent to a server that you have already authenticated against -- otherwise, TRACE will not return the authentication string. Practically speaking, then, this is an attack from a hacked friendly server (because a malicious server would be able to access your authentication information directly), and the TRAC
      • Most sites that any user would be interested in stealing the credentials from will be cookie based logins. Thus it doesn't matter that much where it all happens, I don't think.

        My guess though is that this is really a bug in xmlHTTP (on both Mozilla and IE) because it really shouldn't send these credentials via TRACE, IMHO. And it's access to the credentials thats the issue.
        • #Most sites that any user would be interested in stealing the
          #credentials from will be cookie based logins

          That may well be true. I am not aware, for instance, of any financial institutions that use HTTP Basic authentication. (Because, let's face it, transferring the username and password in cleartext look's pretty silly from our perspective today). However, existing XSS attacks allow you to access a user's cookie -- the XST attack is interesting because it gives you access to the authentication strin
          • Some of the commentary on Bugtraq has made a similar point, that XMLHTTP should not allow you to make a TRACE request at all. To be clear, however, the HTTP spec is "at fault" for the decision to return the authentication string during a TRACE request. And the folks implementing the HTTP spec in servers like Apache perhaps share a bit of the "blame", as they don't provide a method to turn off TRACE requests. (The method that I mentioned in the original post uses mod_rewrite.)

            I strongly disagree. At the e
            • #Of course at the end of the day, just like XSS bugs,
              #we'll rarely see this used in practise.

              I agree with this part of your post. The more I think about this particular exploit, the less of a threat I think it represents. It's trivial to forbit TRACE requests if you run a mod_rewrite-enabled Apache, and you should not use HTTP Basic Authentication to secure anything important, for the same reason security-conscious organizations don't use telnet: passwords are sent in cleartext.

              #I strongly disagree
              • No, I believe in the TRACE situation that xmlHttp (which is what is responsible for accessing the credentials in the first place - any other http library wouldn't have access to them) should not include anything the programmer didn't specify in the headers.

                • Re:Hmm... (Score:1)

                  by cbrooks (3267) on 2003.01.24 12:26 (#16351) Journal
                  Hmmm.

                  Somehow, we're talking past each other. Let me define a set of assumptions, because I think that will help us move past this.

                  XMLHTTP is analagous, in a sense, to LWP in Perl. It essentially lets you call a web browser from JavaScript (or VBScript, etc.). According to Microsoft [microsoft.com] , a "client computer can use the XMLHTTP object (MSXML2.XMLHTTP) to send an arbitrary HTTP request, [and] receive the response".

                  One of those arbitrary HTTP requests is an HTTP TRACE. According to the HTTP protocol [w3.org], "The TRACE method is used to invoke a remote, application-layer loop- back of the request message.... TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information."

                  If a user has authenticated against a server using HTTP Basic Authentication, the authentication string is sent as part of the headers in subsequent requests to that server.

                  Therefore, in the XST scenario, let's assume that a user at time t0 authenticates against a friendly (but hacked) server. At time t1, they request a page that contains a live XSS vulnerability, such that an XMLHTTP object makes a TRACE request against the friendly, hacked server. This TRACE request will send the authentication headers to the server, and the server echo them back. The function that initiated the TRACE request now has access to the authentication string.

                  I may now understand your argument. Are you saying that when the TRACE method is called, it should look for an authentication header before making the TRACE request, and remove that header? Or that it should remove all headers (except Content-type)?

                  Hmmm. The second version of that question addresses 1 of my 3 previous arguments -- that XMLHTTP doesn't know where the security problem lies ahead of time. However, it fails on the other two: you have to depend on all vulnerable clients getting patched to have this behavior (i.e. you have to trust the client); and there may be times when it is perfectly valid for the XMLHTTP programmer to request a full TRACE.

                  The stronger argument, I think, is that the flaw is in the implementation of the web server. If you disable a TRACE by default, (or at least make it trivial for a sysadmin to disable TRACE), your server is secure against any client attempting to exploit this vulnerability, and your programmers can make use of the benefits of TRACE.

                  I suppose I should mention that this discussion has helped me see that the flaw is not in the HTTP spec itself -- it is simply in the design decision of those who have implemented it. Also, of course, I'm not intending to criticize those folks -- nobody thought of this vulnerability until a few months ago. The criticism would only apply if they do not now change the implementation.
                  • OK, let me be a little clearer here.

                    If you tried this using (say, for example) LWP wrapped up as a COM object, so that it would be accessible via JavaScript (you can probably do this with the neat tools that ActiveState provide), you would have no vulnerability.

                    Why? Because xmlHttp has EXPLICIT access to the credentials that are internal to IE, and IE passes them to xmlHttp AUTOMATICALLY. No other HTTP library gets such priviledges.

                    Now do you understand why I think this is a bug in xmlHttp? - the very fa
                    • #xmlHttp has EXPLICIT access to the credentials that are internal to IE,
                      #and IE passes them to xmlHttp AUTOMATICALLY. No other HTTP library
                      #gets such priviledges.

                      I believe this [microsoft.com] is what you're referring to:
                      Internet Explorer and various other Windows components (the XMLHttp class of MSXML, for example) use WinInet for their underlying HTTP communications. If you were to write the WinInet code directly, you would have to deal with the authentication challenge programmatically. Internet Explorer and those
                    • This is getting complex, and really gets too deep into whatever layer you happen to be in. But I still think I'm right - this vulnerability is pretty strictly limited to certain clients. It doesn't work for other HTTP client libraries (though might if they used this WinInet thing, whatever that is), and since this is a remote attack the only thing you can assume is the presence of this xmlHttp, which in turn uses WinInet. The vulnerability (exposing credentials) is either in WinInet or xmlHttp, either way i
                    • #The vulnerability (exposing credentials) is either in WinInet or xmlHttp

                      I think we're just going to have to agree to disagree. The JavaScript method never sees the credentials until they have been echoed back by TRACE. If TRACE is turned off at the server, you will not be able to see the credentials using the XST vulnerability, even if no change is made to WinInet / XMLHTTP.

                      #Same issue on Mozilla too - it's only exposed via xmlHttp.

                      I would just note that according to the original white paper, th
                    • I think we're just going to have to agree to disagree. The JavaScript method never sees the credentials until they have been echoed back by TRACE. If TRACE is turned off at the server, you will not be able to see the credentials using the XST vulnerability, even if no change is made to WinInet / XMLHTTP.

                      On this we agree. What I disagree with is where it should be fixed. XSS (and XST) vulnerabilities affect both the user and the server end. While I agree that sites should take action to prevent this, I al
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.