【问题标题】:Do CORS protect against "network-topology violation"?CORS 是否可以防止“网络拓扑违规”?
【发布时间】:2019-06-23 03:17:00
【问题描述】:

我正在搜索默认情况下在浏览器上禁用 CORS 的原因。 我以为我在旧帖子中找到了示例的答案

Why is CORS without credentials forbidden?这里主要关注的是基于网络拓扑的访问控制。 假设您在您的家庭网络上运行 HTTP 服务(事实上,如果您的路由器本身具有 Web 界面,您几乎肯定会这样做)。我们将此服务称为 R,只有连接到您的家庭路由器的机器才能访问该服务。 当您的浏览器访问 evil.example.com 时,该站点会为您的浏览器提供一个脚本,告诉它获取 R 的内容并将其发送回 evil.example.com。即使没有凭据,这也可能很糟糕,因为这违反了本地网络之外的任何人都无法查看本地网络内运行的服务的假设。同源政策阻止了这种情况的发生。

然后我实际上读到了一个关于 CORS 机制的观察,听起来不错

Why is CORS Disabled by Default?CORS 基于从 API 返回的响应标头。拒绝响应请求的不是 API,Web 浏览器明确禁止处理响应。 API 将正常处理请求。

因此我对第一个引用的“示例”表示怀疑:由于启用 CORS 是通过将正确的标头(Access-Control-Allow-Origin, ...)设置到服务器响应中来完成的,什么样的保护将是如果绕过它,“evil.example.com”只需“将标头设置到他的响应中以在客户端上启用 CORS”?

如果是这样,是否还有其他简单示例说明为什么禁用 CORS?

【问题讨论】:

    标签: cors


    【解决方案1】:

    CORS 是一个禁用同源策略的系统。这是一种放松安全措施的手段,而不是安全功能。

    同源策略防止 Site Evil 使用用户的浏览器(和凭据)从 Site Secret 读取数据。

    Site Evil 无法添加 CORS 标头来禁用同源策略并允许它读取站点机密。只有 Site Secret 可以做到这一点。

    同源策略不防御CSRF attacks。如果 Site Trusted 允许 HTTP 请求进行需要身份验证的更改,则应采取措施确保其不会受到 CSRF 的攻击。

    【讨论】:

    • 关于“Site Evil 无法添加 CORS 标头来禁用同源策略并允许它读取站点机密。只有站点机密可以做到这一点。”你能再详细一点吗?如果用户(域 X 上的客户端)进入站点邪恶(域 Y),因此向它发送请求,为什么站点邪恶不能简单地将 CORS 标头添加到响应中 - 使用恶意脚本 - 让用户处理请求使用恶意脚本?
    • @barsyu435 — 来自站点邪恶的响应可以通过 CORS 授予其他站点 JavaScript 访问站点邪恶的权限。只有受信任的站点可以将标头添加到受信任的站点。
    猜你喜欢
    • 2011-11-27
    • 2014-10-14
    • 2011-03-31
    • 2011-05-08
    • 1970-01-01
    • 2013-07-23
    • 2012-07-13
    • 1970-01-01
    • 2021-09-07
    相关资源
    最近更新 更多