在漫漫渗透之路中，眼前一亮的发现一个站。Referer字段没有检查，POST参数中的动态token也没有检查，这不是带一波CSRF的节奏嘛。但是遇到一个之前我没遇到的问题导致我CSRF失败，这个问题或许很简单，但是我是一个小白，大牛看到就不要喷我了。

　　首先我在Burpsuite当中生成了CSRF的POC，发现不行。经过与原始请求对比发现HEADER中少了一个字段，而这个字段就是CSRF成败与否的关键。下面开始不啰嗦上真正知识点。

　　在原来站中这个请求是一个POST的Ajax异步请求。于是在HTTP报文的head头里面就有了这个字段：X-Requested-With: XMLHttpRequest。　服务器明显检查了这个字段，带有的这个字段就会成功，否则就会302重定向到登录页面。于是我构造了一个利用xmlhttprequest 够早了一个POC。

#注释内容（python是最好的语言，至少在我心中如此）：

"""

xmlhttprequest带cookie的方案：

var xhr = new XMLHttpRequest();

xhr.open("POST", "http://xxxx.com/demo/b/index.php", true);

xhr.withCredentials = true; //支持跨域发送cookies　

xmlhttprequest设置head头字段：

xhr.setRequestHeader("POWERED-BY-MENGXIANHUI", "Approve");

xhr.setRequestHeader("Content-Type", "application/xml");  

"""　

于是我想这样可以了吧，然后就发起了新的Ajax请求准备CSRF，但是在Burp中看到，没有字段。

原因：X-Requested-With: XMLHttpRequest在跨域请求中会被去掉（如果跨域配置允许时候可以带着，看配置）。

然后我手动强制加上了这个字段：

xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");

这个时候我发现，原来的报文变成了OPTION包，而不是POST请求报文。

原来这是跨域访问的一种安全检查机制：

首先发起OPTION对目标服务器进行测试，看看这种访问是否安全

在头部字段会出现下面三个

Access-Control-Request-Method: POST
Access-Control-Request-Headers: x-requested-with
Origin: null（跨域Ajax去掉X-Requested-With，带上这个）

当收到服务器端的响应允许后才发送正式POST或者GET请求。

这叫做预检报文，如何不触发预检报文，有三个同时满足的必备条件（三项均成立才行）：

1. 只能是Get、Head、Post方法
2. 除了浏览器自己在Http头上加的信息（如Connection、User-Agent），开发者只能加这几个：Accept、Accept-Language、Content-Type……
3. Content-Type只能取这几个值：
　　application/x-www-form-urlencoded
　　multipart/form-data
　　text/plain

或许有相关的解决办法，我后面研究研究继续搞。