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

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

              by cbrooks (3267) on 2003.01.24 8:39 (#16339) Journal
              #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. At the end of the day the
              #TRACE method is just a plain old echo. There's
              #nothing inherently insecure about it. The security
              #leak comes from the client end.

              Let me make sure that I understand your argument: you believe that XMLHTTP should provide functionality to make a TRACE request against the web server and to listen for the server's response. (Remember that an HTTP 1.1 complaint web server will reply to an HTTP TRACE request by echoing the headers (authentication string and all) to the caller.) When the XMLHTTP client receives the response you believe that it should filter out the authentication string before returning the headers to the program (or function) that called XMLHTTP?

              I disagree with this argument. Here are my reasons:

              1. XMLHTTP doesn't know ahead of time which headers represent a security risk -- the actual security risk could come from several different headers: the authentication string, cookie header(s), or even custom headers that the particular application might set. The most secure client-side solution is to disable TRACE altogether, BUT, this is still not adequate for the following reason:

              2. You are suggesting that the server should return the authentication string but simply trust the client not to display it. This provides wholly inadequate security -- the original XST white paper notes that the vulnerability has been exercised using both XMLHTTP on IE and XMLDOM on Mozilla. It also suggests that there are likely to be many other possible ways to exploit this vulnerability, including Java and Flash. Fixing the problem in the XMLHTTP client does not elimate the problem, it simply closes it in one client.

              3. There are perfectly valid reasons that someone developing XMLHTTP applications might want to do a TRACE -- they may need to debug a problem in their application, and the problem may lie in the authentication string! The security-conscious developer needs to be able to enable TRACE on their development servers, but disable it on production servers.
              • 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.
                • 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],
                  • 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.