全方位了解CORS跨域资源共享漏洞

全方位了解CORS跨域资源共享漏洞

前几天看网络安全abc123大佬发了一篇关于CORS漏洞的文章，质量很高，恰巧我之前也写过一篇，所以这里想按照大佬的思路，从前提知识，原理，利用过程全方面细致的研究一回

1. 前言

想要了解明白这个漏洞，我们就需要知道一些前提

同源策略 (Same Origin Policy)

• 协议
• 域名
• 端口

​ 同时满足这三种条件就是同源，当存在两个站点，其中有一项不满足相同条件的时候，我们即可说这两个站点不是同源站点，而当其中一个站点想请求另外一个站点的资源的时候我们边称它为跨域请求，而由于安全考虑，跨域请求会受到同源策略的限制

不受影响的标签

​ 在HTML中\, \

, \, \

靶机地址： 192.168.1.2:8080

攻击服务器地址：192.168.1.251:8080

当用户登录状态下，访问我们的网站并点击相关按钮的时候，发下没有任何反应，这时候我们来看一下响应体和控制台，发现请求已经被同源策略禁止了

---

第二种，Allow-Origin为 ，Allow-Credentials为 true

这种的话其实也相当于同意了所有站点的跨域请求，一般如果是这种情况，那么漏洞肯定存在并且可以利用，而出现漏洞的原因就是一些开发为了图方便导致的

后端代码长这样

我们测试的时候，通常情况下还是手动加上origin然后将值随便设置成其它域名，结果如下图

同样的我们进行利用

可以利用成功，但是就这么简单吗？当然不是，这是我在虚拟机上下的一个谷歌的盗版浏览器，接下来我用我本机的三个浏览器试试

Firefox：

Chrome：

Microsoft Edge：

所以呢？这是为什么，我们就没办法利用了吗？

先来说下为什么，原因就是SameSite属性，2016年开始，Chrome 51版本对Cookie新增了一个 SameSite属性，为了防止CSRF攻击，陆续的各大厂商的浏览器也都适配了该属性，该属性有什么用呢？如下图所示，展示了SameSite和其它跟cookie有关的设置的基本用途

samesite属性有三个值

• Strict：最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。
• Lax：当开发开发人员没有设置samesite的值得时候，Lax是默认值，规则稍稍放宽，大多数情况也是不发送第三方 Cookie，详细如下图

我们利用页面的请求，可以算作一个AJAX，所以当我们默认情况下去利用不会发送cookie

• None：所有请求中都允许发送cookie，但是如果samesite配置成了none，还必须将cookie加上Secure属性才能够生效

所以当遇到https协议的站点，并且cookie的samesite被设置成None的时候，也可以利用，如下图所示，我将站点改成了https，并且加上了samesite=None以及Secure

利用成功

---

其中当Allow-Origin设置为safe-host（我这里指的就是正确配置了指点允许跨域访问对的站点）就不演示了，肯定是老铁没毛病

第三种，Allow-Origin为 null ，Allow-Credentials为 true

这种情况可以被绕过，因为任何使用非分级协议（如 data: 或 file:）的资源和沙盒文件的 Origin 的序列化都被定义为‘null’，所以我们这里利用iframe标签，使用 data url 格式将src的值直接加载为html（同样的利用成功的前提仍然要考虑我们上述提到的samesite）

利用成功

当然也可以利用h5的新属性srcdoc

同样可以利用

---

3. 安全建议

• Access-Control-Allow-Origin不应该设置为null，也不建议设置为*，做好设置成受信的站点
• Access-Control-Allow-Methods的值可以控制尽量少一些，只留需要用到的请求方法
• 开发人员尽量将cookie安全性设置高一些，例如Httponly,Security，SameSite
• 提高敏感数据安全性，例如加密，身份二次验证等