web基础漏洞-csrf与ajax
1、cors
如果ajax同源，默认会携带目标域的cookie。而如果不同源，则浏览器在发送请求时默认不携带目标域cookie。
ajax跨域时，服务端必须在响应中设置Access-Control-Allow-Origin字段，否则浏览器不会处理响应，会报cors异常。
- ajax跨域不携带cookie，则Access-Control-Allow-Origin设置为*即可，浏览器会处理响应
- ajax跨域携带cookie，在请求中时需要设置withCredentials为true，告知浏览器携带目标域cookie。而服务端需要设置Access-Control-Allow-Origin为当前请求的origin字段，且Access-Control-Allow-Credentials为true，浏览器才会处理响应。否则报cors异常
如果目标域只有一个跨域请求的来源，则可以将Access-Control-Allow-Origin设置为固定值。反之，是多个，则需要动态根据请求的origin进行设置。需要注意，严格对origin进行检查，否则就会造成任意origin都可以携带目标域发起请求，并且获取响应的数据。
2、csrf与cors
在ajax场景中，如果服务端是动态设置Access-Control-Allow-Origin字段，且origin存在绕过，那么攻击者就可以伪造请求携带cookie提交，并成功获取响应，将其转发接收或者直接进行处理。
3、浏览器安全策略
在最新的edge、firefox和burp自带浏览器中，浏览器安全策略，禁止ajax跨域请求携带cookie。即设置withCredentials为true无效，能够正常跨域请求但是不携带目标域cookie。
按照网上流传的分析，浏览器csrf安全策略应该是默认设置cookie的samesite属性Lax，即禁止跨域携带cookie，除非目标域设置cookie的samesite属性为None。但实际测试中，查看浏览器的cookie缓存，都没有默认设置samesite属性为Lax，而之后直接不携带。
下载比较旧的浏览器版本验证，是不存在该安全策略的，csrf模拟成功。至于各浏览器是从何版本加入该安全策略，有待进一步验证。
- 总的来说，随着发展，csrf与cors-ajax场景将逐步被淘汰，如同xxe漏洞的发展
- 另一方面来说，目前仍然存留大量的旧版本浏览器，所以还是需要注意其防护与挖掘
4、ajax与非ajax
对于服务端来说，最主要的是参数的值，具体来说参数的位置是在url参数中、路径参数中、form形式提交、json格式提交，并不那么重要。
所以，服务端接收参数的处理，往往会存在兼容。意味着ajax提交的数据，有时候通过url或者表单提交也是可以的。从而绕过浏览器安全策略和服务端的cors字段限制。
5、其它
浏览器的又一个安全策略，https域下页面不能加载http的资源，会报xxxblock异常。
https标志的cookie，只能在https协议下传输。
