这个cors处理程序安全吗？

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

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抱怨响应分裂漏洞。我应该简单地使用urlencoder.html#encode还是有更多的功能？
在包含空格的情况下，通常删除空格或不添加cors头行吗？

cors比jsonp等早期技术更安全、更灵活。
webapi非常适用于 GET 请求。但是，一旦你开始使用它 POST, PUT or DELETE 操作，然后cors启动并删除命中服务器的请求。cors停止任何跨域请求，因此如果您的api在 www.myapi.com 以及一个来自 www.mywebsite.com 如果进来，请求将被删除。这是一个安全特性，用于确保来自未知域的请求不会命中服务器。
如果您使用web客户机来执行ajax调用，那么您还需要向ajax调用中添加一件事，以确保cors在所有浏览器上都支持words。

$.support.cors = true
crossDomain: true

资源链接：

如何在webapi中实现跨域请求（cors），老派？
但在一行中，如果我们想说，那么cors处理程序是不安全的。@zapl已经给出了这方面的信息。
现在我试着给你一些攻击类型和一些场景。希望它能给你明确的信息。

cors安全？

cors的不正确实现导致了几个安全问题，最常见的是在服务器头中使用通用的allow符号（*）。
客户端不应完全信任接收到的内容，也不应在未经清理的情况下评估或呈现内容，这可能会导致信任错位。
允许COR的应用程序可能容易受到csrf攻击。
飞行前响应的长时间缓存可能会导致由于滥用飞行前客户端缓存而引起的攻击。
基于源站标头的访问控制决策可能会导致漏洞，因为攻击者可能会欺骗这些漏洞。

cors安全-通用允许

将“access control allow origin”标头设置为*
有效地将内容转化为公共资源，允许从任何域进行访问。
情节：
通过诱使用户访问攻击者控制的站点，攻击者可以从已将此标头设置为*的intranet站点窃取数据
在互联网上。
当受害者导航到攻击者控制的站点时，攻击者可以通过受害者的浏览器对其他远程应用程序执行攻击。

cors安全-信任错位

两个域之间的数据交换是基于信任的
如果参与数据交换的其中一个服务器遭到破坏，那么cors的模型就处于危险之中
情节：
攻击者可以在站点b信任站点a通过cors请求发送给站点b的数据的情况下危害站点a并承载恶意内容，从而导致xss和其他攻击。
攻击者可以破坏站点b并使用站点a中公开的cors功能来攻击站点a中的用户。

带cors的csrf

在验证是否设置了源标头时，服务器可能会处理更改服务器端数据的客户端请求
攻击者可以使用xhr的.withcredentials=“true”属性将任何cookie重放到受害者登录的应用程序中
情节：
攻击者设置源站标头或使用受信任站点a向站点b发送非幂等请求。
受害者在查看受信任的站点a时登录到站点b，导致站点b在他不知情的情况下创建用户帐户
通过csrf攻击。

cors–飞行前响应缓存

access control max age标头设置为一个高值，允许浏览器缓存飞行前响应。
长时间缓存飞行前响应可能会带来安全风险。
如果服务器上的cor访问控制策略更改，浏览器仍将遵循飞行前结果缓存中可用的旧策略。

cors–基于原点的访问控制

origin头表示请求来自特定的域，但并不保证它。
如果访问基于此标头，则欺骗源标头允许访问该页
情节：
攻击者将源站标头设置为查看受限制的敏感信息
攻击者使用curl设置自定义源标题：

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

下面是一个例子。您可以通过以下链接：
https://www.owasp.org/index.php/test_cross_origin_resource_sharing_（otg-client-007）
html5 COR的一些安全影响或如何使用浏览器作为代理

这个cors处理程序安全吗？

1条答案