Question

我写了这个简单的方法来处理我的简单服务器代理中的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标题吗？

Answer 1

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

对于GET请求，WebAPI开箱即用。但是，一旦您开始将其用于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（In）security？

不正确的实施会产生一些安全问题 CORS，最常用的是通用允许符号（*）服务器标题。
客户不应完全信任收到的内容，并且eval或在没有消毒的情况下呈现内容，这可能导致错位信任。
允许CORS的应用程序可能容易受到CSRF的攻击攻击。
Preflight响应的长时间缓存可能会导致攻击由于滥用Preflight Client Cache而引起的。
基于Origin标头的访问控制决策可能导致这可能是攻击者欺骗的漏洞。

CORS安全 - 通用允许

设置＆＃39; Access-Control-Allow-Origin＆＃39;标题为*
有效地将内容转换为公共资源，允许从任何域访问。

情景：



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



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

CORS安全 - 错位信任

两个域之间的数据交换基于信任
如果涉及数据交换的其中一个服务器是然后妥协，CORS的模型处于危险之中

<强>方案：


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

攻击者可以危害站点B并使用站点A中公开的CORS功能来攻击站点A中的用户。

CSRF与CORS

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

<强>方案：


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

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

CORS - 预检回应的缓存

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

CORS - 基于Origin的访问控制

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

<强>方案：


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

攻击者使用cURL设置自定义原始标题：

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

这是一个例子。您可以浏览此链接：

这个CORS处理程序安全吗？

1 个答案: