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

use Perl Log In

Log In

[ Create a new account ]

cbrooks (3267)

cbrooks
  (email not shown publicly)

Journal of cbrooks (3267)

Thursday January 23, 2003
12:06 AM

Cross-Site Tracing (XST) security vulnerability

[ #10132 ]
Ilya has already mentioned this, but he has comments disabled, so I thought I'd make an entry as well.

XST is a newly-reported vulnerability that combines traditional XSS (cross-site-scripting) attacks with HTTP TRACE. The traditional XSS part of the attack is that a blackhat could embed a malicious JavaScript (or other client-side scripting language) function in a web application that does not properly screen client input. The JavaScript function in turn can craft an HTTP TRACE request (using the XMLHTTP ActiveX control in IE or XMLDOM in Mozilla). HTTP TRACE simply echoes your HTTP request, including HTTP Basic Authentication strings (which are passed as base64-encoded cleartext), which apparently makes this new attack noteworthy. XSS attacks could not previously access Authentication strings.

The tone of commentary on Bugtraq generally seems to downplay the severity of this vulnerability for two reasons: (1) very few people have ever seen XSS attacks in the wild; and (2) the vulnerability would be largely mitigated were Microsoft to simply remove XMLHTTP's ability to send an HTTP TRACE request.

If you use HTTP Basic Authentication on your server, you can protect against this method of reading authentication strings by disabling TRACE requests. Disabling TRACE on Apache is trivial, assuming that you have compiled Apache with mod_rewrite:

##########################
#
#This rule is in response to http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
#
RewriteEngine On
#Test the server variable REQUEST_METHOD to see if it matches the pattern ^TRACE
RewriteCond %{REQUEST_METHOD} ^TRACE
#
#Match 0 or more of any character, No substitution, return FORBIDDEN (403)
RewriteRule .* . [F]
#
#########################

(Comments are mine, mod_rewrite directives are from the white paper mentioned above.)

List all Journal entries
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.
                • 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.