三种对CORS错误配置的利用方法

同源战略(SOP)约束了应用程序之间的信息同享,而且仅答应在保管应用程序的域内同享。这有用避免了体系秘要信息的走漏。但与此一起,也带来了别的的问题。跟着Web应用程序和微服务运用的日益增...

同源战略(SOP)约束了应用程序之间的信息同享,而且仅答应在保管应用程序的域内同享。这有用避免了体系秘要信息的走漏。但与此一起,也带来了别的的问题。跟着Web应用程序和微服务运用的日益增长,出于有用意图往往需求将信息从一个子域传递到另一个子域,或许在不同域之间进行传递(例如将拜访令牌和会话标识符,传递给另一个应用程序)。
为了答应跨域通讯,开发人员有必要运用不同的技能来绕过SOP并传递灵敏信息,以至于如今也成为了一个扎手的安全问题。因而,为了在不影呼应用程序安全状况的状况下完结信息同享,在HTML5中引入了跨源资源同享(CORS)。但问题也随之而来,许多人为了便利爽性直接运用默许的装备,或是因为缺少对此的了解而导致了过错的装备。
因而,作为安全分析师/工程师,了解怎么运用过错装备的CORS标头非常重要。这也将有助于你在灾祸发作之前更好地对其进行弥补。
什么是 CORS?
CORS是一个W3C规范,全称是”跨域资源同享”(Cross-origin resource sharing)。它答应浏览器向跨源(协议 + 域名 + 端口)服务器,宣布XMLHttpRequest恳求,然后克服了AJAX只能同源运用的约束。
CORS需求浏览器和服务器一起支撑。它的通讯进程,都是浏览器主动完结,不需求用户参加。关于开发者来说,CORS通讯与同源的AJAX通讯没有不同,代码彻底相同。浏览器一旦发现AJAX恳求跨源,就会主动增加一些附加的头信息,有时还会多出一次附加的恳求,但用户不会有感觉。
因而,完结CORS通讯的要害是服务器。只需服务器完结了CORS接口,就能够跨源通讯。
要害 CORS 标头
有许多与CORS相关的HTTP标头,但以下三个呼应标头关于安全性最为重要:
Access-Control-Allow-Origin:指定哪些域能够拜访域资源。例如,假如requester.com想要拜访provider.com的资源,那么开发人员能够运用此标头安全地颁发requester.com对provider.com资源的拜访权限。
Access-Control-Allow-Credentials:指定浏览器是否将运用恳求发送cookie。仅当allow-credentials标头设置为true时,才会发送Cookie。
Access-Control-Allow-Methods:指定能够运用哪些HTTP恳求办法(GET,PUT,DELETE等)来拜访资源。此标头答应开发人员经过在requester.com恳求拜访provider.com的资源时,指定哪些办法有用来进一步增强安全性。
三个进犯场景
运用CORS标头中过错装备的通配符(*)
最常见的CORS装备过错之一是过错地运用比如(*)之类的通配符,答应域恳求资源。这一般设置为默许值,这意味着任何域都能够拜访此站点上的资源。例如:
GET /api/userinfo.php
Host: www.victim.com
Origin: www.victim.com
当你发送上述恳求时,你将取得具有Access-Control-Allow-Origin标头设置的呼应。请参阅以下呼应代码。
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
在此示例中,标头装备了通配符(*)。 这意味着任何域都能够拜访资源。
在测验咱们客户的Web应用程序时,咱们留意到了这种过错装备。咱们能够运用它来获取用户信息,如名字,用户ID,电子邮件ID,并能够将此信息发送到外部服务器。鄙人图中,咱们将REQUEST Origin从受害者域修改为进犯者域。

以下是咱们收到的呼应,这意味着受害域答应拜访来自一切站点的资源。咱们的进犯事例中的Testing.aaa.com网站。

因为该站点同享来自任何站点的信息,因而让咱们进一步的运用咱们自己的域来运用它。咱们创建了名为https://testing.aaa.com的域,并将其嵌入缝隙运用代码,以便从易受进犯的应用程序中盗取秘要信息。当受害者在浏览器中翻开https://testing.aaa.com时,它会检索灵敏信息并发送给进犯者的服务器。以下是咱们能够收集到的信息,如下图所示。

将信赖域通配符作为 Origin
另一种常见的过错装备是答应与部分验证的域名同享信息。例如,以下恳求:
GET /api/userinfo.php
Host: provider.com
Origin: requester.com
呼应如下:
HTTP/1.0 200 OK
Access-Control-Allow-Origin: requester.com
Access-Control-Allow-Credentials: true
考虑一下开发人员是否装备了CORS来验证“Origin header”URL,白名单域仅仅“requester.com”。现在,当进犯者建议如下恳求时:
GET /api/userinfo.php
Host: example.com
Connection: close
Origin: attackerrequester.com
服务器会呼应:
HTTP/1.0 200 OK
Access-Control-Allow-Origin: attackerrequester.com
Access-Control-Allow-Credentials: true
发作这种状况的原因可能是后端装备过错,例如:
if ($_SERVER['HTTP_HOST'] == '*requester.com')
 {
  //Access data
  else{ // unauthorized access}
}
咱们在客户的一个应用程序中遇到了这个问题。主机域“provider.com”信赖以主机名“requester.com”结束的一切来历,例如“attackerrequester.com”。 因而,咱们将origin头部篡改为attackerrequester.com并持续履行恳求。

在以下呼应中,相同的origin在呼应Access-control-Allow-Origin标头中,这意味着provider.com域答应同享资源到以requester.com结束的域。

[1] [2]  黑客接单网

  • 发表于 2021-04-08 11:35
  • 阅读 ( 2 )
  • 分类:生活经历

0 条评论

请先 登录 后评论
凡齐商学院
凡齐商学院

13 篇文章

你可能感兴趣的

相关问题