HTTP定义了一组请求方法,以表明要对给定资源执行的操作。指示针对给定资源要执行的期望动作。 虽然他们也可以是名词, 但这些请求方法有时被称为HTTP动词. 每一个请求方法都实现了不同的语义。其中,TRACE方法沿着到目标资源的路径执行一个消息环回测试。
关于TRACE方法
客户端发起一个请求时,这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在 最终将请求发送给服务器时,看看它变成了什么样子。
TRACE 请求会在目的服务器端发起一个 环回 诊断。行程最后一站的服务器会弹回一条 TRACE 响应,并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求 / 响应链上,原始报文是否,以及如何被毁坏或修改过。
TRACE方法主要用于诊断。也就是说,用于验证请求是否如愿穿过了请求 / 响应链。它也是一种很好的工具,可以用来查看代理和其他应用程序对用户请求所产生效果。
尽管TRACE可以很方便地用于诊断,但它确实也有缺点,它假定中间应用程序对各种不同类型请求(不同的方法——GET、HEAD、POST 等)的处理是相同的。很多HTTP应用程序会根据方法的不同做出不同的事情——比如,代理可能会将POST请求直接发送给服务器,而将GET请求发送给另一个HTTP应用程序(比如Web缓存)。TRACE并不提供区分这些方法的机制。通常,中间应用程序会自行决定对TRACE请求的处理方式。
TRACE 请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。当TRACE请求到达目的服务器时, 整条请求报文都会被封装在一条HTTP响应的主体中回送给发送端。当TRACE响应到达时,客户端可以检查服务器收到的确切报文,以及它所经过的代理列表(在 Via 首部)。TRACE 响应的 Content-Type 为 message/http,状态为 200 OK。
关于跨站跟踪攻击(CST/XST)
CST攻击是一种使用XSS和HTTP TRACE功能来进行攻击的方式。它是一种攻击技巧,可以利用它避开HttpOnly对cookie提供的保护,使之能够通过客户端JavaScript获取已经标记为HttpOnly的cookie值。
正常情况下,客户端脚本(如JS脚本)是可以通过document.cookie函数获得,这样如果有XSS跨站漏洞,cookie很容易被盗取。浏览器有一个安全策略,通过设置cookie的httponly属性,这样客户端脚本就不能通过document.cookie访问该cookie,即时有跨站漏洞,也不能盗取用户cookie。(注意:httponly属性对正常的HTTP请求并没有影响,即时Cookie设置了HTTPONLY属性,当用户浏览有效域中的站点时候,这个Cookie仍然被自动发送,只是不能使用脚本来访问该Cookie。(解释HTTPONLY)
一般客户端向服务器请求是利用HTTP GET和POST方式,但那只是常见,还有其它方式(详细参考RFC2616文档)。其中HTTP TRACE也是一种方式,这种向服务端请求信息主要用于调试web服务器连接用。如果请求有效,则在响应中会在实体中包含整个请求消息。(解释HTTP TRACE)
测试用例
某应用程序服务端启用了TRACE方法,先看原始请求/响应数据,如下图所示:
响应主体中携带它收到的原始请求报文:
原始响应下会下载一个未知格式的文件。因此此例中需要除了需要在请求头中构造恶意脚本以外,同时篡改客户端解析类型和方式,将响应中的Content-Type:message/http,改为Content-Type:text/html,如下图:
从而使得客户端成功执行构造的脚本:
CST与XSS的联系和区别:
联系:CST是XSS的一种子类,也属于XSS跨站漏洞。
区别:浏览器请求的方式不一样,普通的XSS一般通过GET和POST方式在页面上输入攻击脚本实现,但是CST如果要在页面上输入,需要找到会通过TRACE发送的输入点,一般是自己构造攻击报文在TRACE方法中进行发送。
测试相关:
由于普通的XSS攻击报文可以通过GET或者POST被提交,而CST则要通过TRACE来提交,由于比较少用,目前还未搜索到有页面输入框可以使用TRACE提交的。因此对它的测试需要注意,攻击脚本中需要自己提供发送函数,比如使用XMLHttpRequest发送请求(当然普通的XSS攻击也需要覆盖用XMLHTTPRequest发送GET、POST请求)。
测试总结:对CST的测试只需要将普通XSS的攻击特征脚本放在HTTP的TRACE位置发送出去即可。