论文阅读2018：We Still Don’t Have Secure Cross-Domain Requests: an Empirical Study of CORS

最新推荐文章于 2022-11-16 16:22:39 发布

我的喵喵找不到了

最新推荐文章于 2022-11-16 16:22:39 发布

阅读量488

点赞数

分类专栏：论文阅读文章标签： USENIX web安全 CORS

本文链接：https://blog.csdn.net/qq_30050175/article/details/88226052

版权

论文阅读专栏收录该内容

18 篇文章 1 订阅

订阅专栏

作者介绍

This paper is included in the Proceedings of the 27th USENIX Security Symposium.August 15–17, 2018 • Baltimore, MD, USA
Jianjun Chen：Tsinghua
Jian Jiang：Shape Security

摘要

默认的同源策略实质上将访问跨域网络资源限制为“只写”。但是，许多Web应用程序需要“读取”访问来自不同来源的内容。开发人员提出了一些解决方法，例如JSON-P，以绕过默认的同源策略限制。这种临时解决方案留下了许多固有的安全问题。 CORS（跨源资源共享）是一种更加自律的机制，所有Web浏览器都支持它来处理跨域网络访问。本文介绍了我们对CORS实际应用的实证研究。我们发现CORS的设计，实现和部署受到许多新的安全问题的影响：

CORS以一些在实践中存在问题的微妙方式放松了交叉起源的“写”特权;
CORS将新形式的风险信任依赖带入Web交互;
开发人员通常不会很好地理解CORS，可能是因为它的策略不及时以及与其他Web机制的复杂而细微的交互，导致各种错误配置。

最后，我们提出协议简化和内容的清晰明了，以减轻我们研究中发现的安全问题。我们的一些建议已被CORS规范和主要浏览器采用。

研究动机

JSON-P可以访问导入的跨源JavaScript以解决同源策略限制问题，但它存在安全隐患。CORS的提出以允许访问跨源资源（2009）。对CORS协议的设计、使用、开发及新的安全事件中来研究CORS的安全性。

发现的问题

过度宽松的交叉发送权限；
CORS固有的安全隐患；
复杂的CORS细节以及大量的配置错误。

贡献

对CORS在设计、应用、开发方面进行了复杂的安全研究；
发现了许多新的与CORS相关的安全问题，并通过实际攻击证明了它们的后果；
对流行网页CORS配置的测量研究，并提出了新的识别CORS错误配置的工具；
总结并强调了存在安全问题的原因，并提出建议（简单化、清晰化）

论文结构

1.Introduction
2.CORS发展
3.实验方法
4. 5. 6. CORS安全问题
7.协议简单化
8. 回复
9.相关工作
10.总结

Timeline

实验部分

model

web attackers & active network attackers

实验方法

参考：
W3C发布跨源资源共享（CORS）的正式推荐标准
WHATWG’s Fetch standard

研究了CORS实现，包括5个主流浏览器和11个流行的开源Web框架，以了解CORS功能在实践中的实现方式。
对Alexa Top 50,000网站进行了大规模测量，包括其97,199,966个不同的子域名。对于每个域，我们使用不同的请求标识发送跨源请求，以检查响应标头中的CORS策略。

实验总结

CORS安全问题概述

Overly Permissive Sending Permission

Crafting Request Headers

1.CORS允许在其新的JavaScript接口（例如，XML-HttpRequest Level2，fetch）中默认自由发送“简单请求”。然而，这些新的接口（后来称为“CORS接口”）实际上隐含地进一步放宽了发送权限，无意中允许在CORS简单请求中恶意定制HTTP头和主体。

对五种主流浏览器（Chrome，Edge，Firefox，IE，Safari）的测试中，除了Safari之外，除了Content-Type之外的任何标题都没有任何限制。
eg. “(){:;};”(不断递归，不停地制造后台任务，Shellshock漏洞)

将Content-Type限制为三个特定值（“text / plain”，“multipart / form-data”，“application / x-form-url-encoded”），可以绕过限制。所有这些前缀匹配三个值并忽略第一个逗号或分号之外的剩余值。因此，攻击者仍然可以通过将攻击有效负载附加到有效值来在Content-Type标头中创建恶意内容。网络攻击者可以使用CORS简单的请求操纵受害者的浏览器来制作利用有效负载。

实验：在本地网络中建立了一个Apache Struts环境，该环境具有s2-045漏洞（内部网络中，因此来自外部网络的网络攻击者应该是不可利用的)，在CORS的帮助下，我们确认攻击者可以设置一个网页，通过Content-Type标头发送带有恶意负载的跨域请求。内联网受害者访问此页面后，将触发此漏洞。在我们的实验中，此攻击使我们能够在内部服务器上获取shell。

2.CORS对标头大小的限制很少。
在HTTP或CORS标准中，请求标头大小没有明确的限制。我们测试了五个主要浏览器，发现它们都允许在CORS接口中至少有16MB的一个或多个标头。当我们将标头设置为非常大的值（例如，1 GB）时，浏览器产生“没有足够的内存”错误，而不是“标头大小太大”错误。这比其他Web组件（例如，Web服务器）强制执行的请求大小限制要大得多。

侧信道攻击：攻击者首先通过直接发出具有增加大小标头的请求来测量目标Web服务器的标头大小限制，直到收到400 Bad Request响应。然后攻击者在受害者的浏览器中发送“简单请求”，并使用精心设计的标头值，使标头大小略小于测量限制。如果存在cookie，cookie将自动附加在请求中。总标头大小将超过限制，从而产生400 Bad Request响应。如果没有cookie，目标服务器将返回200 OK响应。& 时间长短判断->推断出有关受害者cookie的更多细节;存在cookie可能泄露有关受害者的私人信息

Crafting Request Bodies

1.CORS缺乏对body格式的限制

“application/x-www-form-urlencoded”: name1 = value & name2 = value
“text/plain”: = , 回车
“multipart/form-data”：form-data; name = “title”; filename = “myfile”.

实验：对body格式的限制。测试了五个浏览器，发现它们都允许JavaScript以任何格式发送带有正文数据的跨源请求。组合请求机构的这种灵活性可能导致新的安全问题。攻击者可以利用以前无法利用的文件上传CSRF漏洞。在HTML表单中，文件选择控件的“文件名”属性不能由JavaScript控制，并且仅当用户在文件对话框中进行选择时才由浏览器自动设置。在CORS之前，检查服务器端是否存在“filename”属性足以阻止文件上载CSRF。然而，CORS打破了这种防御，允许攻击者设计身体设置“文件名”属性，从而能够启动文件上传CSRF攻击。我们在JD.com（Alexa等级20）的个人帐户页面中发现了这种情况，除了上传文件以更改用户的头像外，其在每个输入位置都有CSRF防御。没有CORS，这种脆弱性是不可行的。我们确认，使用CORS，攻击者可以利用此CSRF漏洞来修改受害者的头像。

2.CORS缺乏对body值的限制

浏览器中的CORS标准和CORS接口对请求体的值没有任何限制，这为攻击者提供了更大的灵活性。

可以利用基于二进制的协议服务。测试了MacOS内置的AFP服务器，发现它总是使用16字节对齐来解析数据，忽略任何无法识别的16字节帧并继续解析下一个16字节帧。通过利用CORS接口，攻击者可以创建一个跨源请求，使其头大小为16字节的倍数，AFP服务器会忽略它，并构建其AFP协议格式的二进制体，以便与AFP通信服务器。我们在实验中证明了这种攻击：通过从公共网站发送跨源请求，我们可以在位于我们受其他方式保护的Intranet中的AFP服务器上创建新文件。

Risky Trust Dependency

HTTPS Site Trust HTTP Domain

如果HTTPS站点配置了CORS并信任其自己的HTTP域，则MITM攻击者可以首先填充可信HTTP域，然后将来自此域的跨源请求发送到HTTPS站点，并间接读取HTTPS域下的受保护内容。

Fedex.com 配置CORS并信任其HTTP域，因此MITM攻击者可以首先劫持HTTP域，然后发送跨源请求以读取HTTPS内容。在实验中验证了此攻击：它允许攻击者阅读详细的用户帐户信息，例如用户名，电子邮件地址，家庭地址，Fedex.com上的信用卡。

Trusting Other Domains

Trusting all of its own subdomains：利用子域攻击主域
Trusting third-party domains：利用第三方攻击

CORS Measurement

CORS测量：针对Alexa Top 50,000域名，并且利用DNS数据库提取子域名。在49,729个不同的基础域上收集了97,199,966个不同的子域。

实验方法：在不同的测试请求中反复将Origin头值更改为不同的易出错值，并根据响应头推断出它们的CORS配置。

eg. 测试HTTPS trusts HTTP，在origin header 置：“Origin: http://example.com”
如果收到“Access-Control-Allow-Origin:http://example.com”，则代表成功。

结果：481,589 sub-domains over 22,049 base domains

HTTP：
1）标准并没有明确强调安全风险。2）某些Web框架无法检查协议类型。3）一些Web应用程序允许http和https协议类型以实现更好的兼容性

trusting third-party domains：
1）标准中没有风险警告。 2）信任任意第三方子网简化了Web开发人员配置

Complex Policies and Misconfigurations

开发web 框架

1.Poor Expressiveness of CORS Policy

盲目地反映请求者在响应头中的origin;
尝试验证请求者的origin但是犯了错误。
Access-Control- Allow-Origin header value：null，*，value

2.Origin Forgery

CORS stan- dards also lack clear definition of null value

3.Complexity of Security Mechanisms

Access-Control-Allow-Origin=“”限制规则：“Access-Control-Allow-Origin：”和“Access-Control-Allow-Credentials：true”不能同时使用。
但是很多web不知道

4.CORS and Cache

大多数Web代理仅基于URL缓存HTTP内容，而不考虑相关的CORS策略。如果使用针对一个域的CORS策略缓存与多个域共享的资源，则由于CORS策略违规，其他域将无法访问该资源。

讨论

向后兼容性需要恰到好处，过度反而会降低安全性
在部署时对新协议进行全面评估——不能不成熟的情况下用啊
协议人员应充分学习协议的安全性；规则要强调，标准需时刻更新

提升：

默认的发送权限应该更具限制性：Access-Control-Max-Age来缓存预检请求
限制CORS简单请求格式和值
CORS配置更加简洁明了
null定义需清晰
风险等级需要严格评估和总结

相似工作

Cross-Origin Sending Problems
CORS Misconfiguration Problems
Other Cross-Origin Problems

感悟

什么是CORS
CORS安全隐患
CORS安全隐患的修补策略
对新协议应用的敏感性

我的喵喵找不到了

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
论文阅读2018：We Still Don’t Have Secure Cross-Domain Requests: an Empirical Study of CORS

We Still Don’t Have Secure Cross-Domain Requests: an Empirical Study of CORS作者介绍相关知识CORSSame Origin Policy跨源发送的风险Cross Site Request Forgery (CSRF)HFPA摘要研究动机发现的问题贡献论文结构实验部分model实验方法实验总结Crafting Request...
复制链接

扫一扫