这个 CORS 处理程序安全吗？答案

【问题标题】：Is this CORS handler safe?这个 CORS 处理程序安全吗？
【发布时间】：2016-09-04 15:49:02
【问题描述】：

我写了这个简单的方法来在我的一个简单的服务器代理中处理 CORS。

private void handleCors(HttpServletRequest req, HttpServletResponse resp) {
  final String origin = req.getHeader("Origin");
  if (Strings.isNullOrEmpty(origin)) {
    return;
  }
  if (!origin.startsWith("http://localhost:")) {
    return;
  }
  resp.setHeader("Access-Control-Allow-Origin", origin);
  resp.setHeader("Access-Control-Allow-Credentials", "true");
  resp.setHeader("Access-Control-Expose-Headers", "Authorization");
  resp.setHeader("Access-Control-Allow-Headers", "Authorization, Content-Type");
}

真正的应用程序不需要它，它只在手动测试时使用（ionic serve）。我想，这是安全的，因为除了源是 localhost 之外什么都不做，但比抱歉更安全。

此外，findbugs 抱怨response splitting vulnerability。我应该简单地使用URLEncoder.html#encode 还是还有更多？

一般会在包含空格的情况下删除空格或不添加 CORS 标头吗？

【问题讨论】：

在浏览器之外，您可以发送各种标头，包括以http://localhost: 开头并包含拆分响应的尝试。我不知道为什么有人会关心，因为那时你无论如何都可以做任何事情。对于来自合法浏览器的常规请求，这应该是安全的，因为该源头是浏览器生成的。如果它包含恶意内容，我猜攻击者已经控制了浏览器，所有希望都落空了。

标签： java cors

【解决方案1】：

CORS 比 JSONP 等早期技术更安全、更灵活。

WebAPI 可以直接用于GET 请求。但是，一旦您开始将它用于 POST, PUT or DELETE 操作，然后 CORS 就会启动并丢弃访问服务器的请求。 CORS 会停止任何跨域请求，因此如果您的 api 在www.myapi.com 上运行并且来自www.mywebsite.com 的请求进入，则该请求将被丢弃。这是一项安全功能，可确保来自未知域的请求无法访问服务器。

如果您使用 Web 客户端执行 ajax 调用，那么您还需要在 ajax 调用中添加一件事，以确保所有浏览器上的 CORS 字词。

$.support.cors = true
crossDomain: true

资源链接：

How to Implement Cross Domain Requests (CORS) in WebAPI, old school?

但是在一行中，如果我们想说 CORS 处理程序是不安全的。已经@zapl 提供了这方面的信息。

现在我试图给你一些带有一些场景的攻击类型。希望它能给你明确的信息。

CORS（内）安全性？

执行不当会导致几个安全问题 CORS，最常在服务器标头。
客户端不应完全信任接收到的内容，并且评估或渲染内容而不进行可能导致错位的清理信任。
允许 CORS 的应用程序可能会受到 CSRF 的攻击攻击。
预检响应的长时间缓存可能会导致攻击由于滥用 Preflight 客户端缓存而引起的。
基于 Origin 标头的访问控制决策可能会导致漏洞，因为这可能被攻击者欺骗。

CORS 安全性 - 通用允许

将“Access-Control-Allow-Origin”标头设置为 *
有效地将内容变成公共资源，允许从任何域访问。

场景：

攻击者可以通过诱使用户访问攻击者控制的站点从已将此标头设置为 * 的 Intranet 站点窃取数据
在互联网上。

当受害者导航到攻击者控制的站点时，攻击者可以通过受害者的浏览器对其他远程应用程序进行攻击。

CORS 安全性 - 错误的信任

两个域之间的数据交换基于信任
如果参与数据交换的服务器之一是受到损害，则 CORS 模型面临风险

场景：

知道站点 B 信任站点 A 通过 CORS 发送到站点 B 的数据，攻击者可以破坏站点 A 并托管恶意内容请求导致 XSS 和其他攻击。

攻击者可以破坏站点 B 并使用站点 A 中暴露的 CORS 功能来攻击站点 A 中的用户。

带有 CORS 的 CSRF

服务器可能会处理客户端请求以更改服务器端数据，同时验证是否设置了 Origin 标头
攻击者可以使用 XHR 的 .withCredentials = “true” 属性将任何 cookie 重播到记录受害者的应用程序在

场景：

攻击者设置 Origin 标头或使用受信任的站点 A 向站点 B 发送非幂等请求。

在查看受信任站点 A 时登录站点 B 的受害者导致站点 B 在他不知情的情况下创建用户帐户
通过 CSRF 攻击。

CORS - 预检响应的缓存

Access-Control-Max-Age 标头设置为高值，允许浏览器缓存 Preflight 响应。
将预检响应缓存更长的时间可能会造成安全风险。
如果在服务器上更改了 COR 访问控制策略，则浏览器仍将遵循 Preflight 中可用的旧策略结果缓存。

CORS - 基于来源的访问控制

Origin 标头表示请求来自特定的域，但不保证。
欺骗 Origin 标头允许访问页面，如果访问权限基于此标头

场景：

攻击者设置 Origin 标头以查看受限的敏感信息

攻击者使用 cURL 设置自定义源头：

     curl --header 'origin:http://someserver.com' http://myserver.com:90/demo/origin_spoof.php

这里给出一个例子。你可以通过这个链接：

【讨论】：