跨域漏洞那些事儿（cors、jsonp) _跨域漏洞

声明
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，雷神众测以及文章作者不为此承担任何责任。
雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经雷神众测允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。
前言
近期在src挖掘中经常看到大佬们提到cors,josnp一直不太理解此类漏洞。特此学习记录一下，如有错误之处还望师傅们斧正。
No.1
跨域资源共享（cors)
跨域资源共享(cors)原理：
在讲cors之前我们先来了解一下同源策略（sop）。
1.1 同源策略
浏览器的安全基石是同源策略。同源策略保证了同一个浏览器打开不同网站，不同网站之间不会相互影响。
列如：张三登陆了某银行网站，浏览器存储了他的cookie 。而这时他又打开了另一个小网站，该小网站会记录用户的cookie 。如果没有同源策略，他就会记录浏览器存储的cookie，此时银行网站的cookie也被记录，从而造成银行用户cookie泄露。
同源策略中的同源是指：
三个同源：同协议，同域名，同端口，例如：
https://www.test.com 和 http://www.test.com (不同源，协议不同)
http://www.test.com 和 http://login.test.com (不同源，域名不同)
http://www.test.com:80 和 http://www.test.com:8080 (不同源，端口不同)
1.2 同源策略(sop)的窗口跨域资源共享(cors)
但是安全和方便总是难两全。张三新开发了一个网站A，要从网站B上获取数据，但是因为同源策略的存在他获取不了B网站上的数据。此时他通过搜索发现一个叫做跨域资源共享的东西经过一通配置，他成功获取到了B网站的数据：
他的配置如下：
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
这个配置在满足要求的同时也造成了严重的安全问题，Access-Control-Allow-Origin: * 通配符* 允许A网站访问的同时也允许了其他任意网站的访问。假设一个攻击过程：
网站C的cors配置存在缺陷，被一个黑客发现，该黑客通过友链申请，给站长发送了一个网站链接，站长为了确认友链网站，打开了网站链接，而该网站中部署了黑客精心构造的恶意脚本，能够自动获取存储网站C中的cookie信息，此时黑客就获取到了站长的cookie信息...
配置讲解：
Access-Control-Allow-Origin：*
web浏览器将Access-Control-Allow-Origin与请求网站的来源进行比较，如果匹配则允许访问响应
例如：Access-Control-Allow-Origin：http://www.test.com
此时网站login.test.com（小A)向www.test.com(小B）发起请求，小B一看请求源（origin）和自己的配置不一样，知道小A可能是个坏蛋，照例将请求返回给小A，但是响应中不含有Access-Control-Allow-Origin标头，万能的浏览器一看跨域请求，响应中还没有Access-Control-Allow-Origin字段，立马报错。坏蛋小A就获取不到小B的数据了...
更多详细讲解可参考阮老师文章：https://www.ruanyifeng.com/blog/2016/04/cors.html
Access-Control-Allow-Credentials: true
该字段可选。它的值是一个布尔值，表示是否允许发送Cookie 。默认情况下，Cookie不包括在CORS请求之中。
设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。
通过前面的介绍我们对cors也知名知意了，这时问题就出现了，这漏洞该怎么挖呢？
这时就要了解一下burpsuite网站的实验室，该实验室中存在多中漏洞实验，在学习漏洞知识的同时也能实战学习漏洞利用技巧，接下来就简单记录一下实验过程。
实验链接：https://portswigger.net/web-security/cors
实战练习：
1.1 来源（origin)可任意更改的cors漏洞