后端已经配置 前端还是报cors错误怎么回事_换一种姿势挖掘CORS漏洞

最近一直在挖CORS配置错误这个问题，但是还没找到像样的案例，就先归纳一下这个漏洞，顺便记录一下学到的新姿势，希望对大家有所帮助

在阅读本文之前，你应该已经知道什么是CORS了，以及CORS配置错误会带来的安全问题，当然不懂也没关系，我用几句话简单给大家描述下这个问题。

CORS基础

CORS的全称是跨域资源访问，我们都知道同源策略（SOP）限制了我们的浏览器跨域读取资源，但是我们在设计开发一些网站的时候，本来就需要跨域读取数据，但是因为有同源策略的存在，我们要跨域就太麻烦了，所以cors应运而生，这个策略可以帮助我们跨域读取资源，具体的做法如下：

1. 当你要发起一个跨域请求时，你的请求头里需要带上Origin头，表明你这个请求来自哪个域
2. 服务端在收到这个请求头的时候，会返回一个access-control-allow-origin头，这个头的值会表明目标服务器是否接受这个跨域请求，如果目标服务器接受这个跨域请求，浏览器就会接受响应，否则浏览器就丢弃这个响应

下面的例子就是一个典型的CORS请求与响应

GET /api/return HTTP/1.1
Host: www.redacted.com
Origin: evil.redacted.com
Connection: close

HTTP/1.1 200 OK
Access-control-allow-credentials: true
Access-control-allow-origin: evil.redacted.com

其中响应中的Access-control-allow-origin头指示了目标域接受来自哪个域的跨域请求

而这个头的值是在目标域的服务端进行配置的，一般这个头的值都会设计成一个白名单，而这个白名单的设计方式就是通过正则实现

本着有正则的地方就会有绕过的原则，我们开搞

情景1

^https?://(.*.)?xxe.sh$

这个正则表明该域接受所有来自xxe.sh域及其子域的请求，这里的配置是没啥问题的，但是如果xxe.sh子域存在xss漏洞或者子域名劫持漏洞的话，那么我们就可以利用了

那有人就要问了：“到底怎么利用 ？我是小白”

ok,我们看一个实例吧，以www.redacted.com/api/return这个接口为例

它的cors配置就类似上述正则那样，允许所有子域访问，经过一番搜索，我在他的一个子域banques.redacted.com发现了一处xss,payload如下：

https://banques.redacted.com/choice-quiz?form_banque="><script>alert(document.domain)</script>&form_cartes=73&iframestat=1