security - request.getHeader ("Origin") 如何防止跨站请求伪造攻击？

Question

我正在开发 Web 应用程序，并要求在发布之前对其运行 VAPT。

然后我下载了Vega并快速扫描了我的网络应用程序并发现了 VAPT 问题，如下所示:

Vega has detected that the resource has set an insecure Cross-Origin Resource Sharing (CORS) access control. CORS provides mechanisms that allow a server to restrict resource access for cross-site requests to certain trusted domains. The server in question has allowed resource from any origin by setting the value of the "Access-Control-Allow-Origin" response header to a wildcard value. This presents a security risk because any site can issue requests to access resources, regardless of origin.

然后我开始寻找解决方案来修复它，并发现 this按照答案中的建议发布并实现了一个过滤器，如下所示:

@Component
public class CORSFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    @Override
    public void doFilter(ServletRequest req, ServletResponse res,
            FilterChain chain) throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;
        HttpServletRequest request = (HttpServletRequest) req;
        response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
        response.setHeader("Access-Control-Allow-Methods",
                "POST, GET, OPTIONS, DELETE");
        response.setHeader("Access-Control-Max-Age", "3600");
        response.setHeader("Access-Control-Allow-Headers", "x-requested-with");
        chain.doFilter(request, response);
    }

    public void destroy() {
    }
}

现在，当我再次针对 Web 应用程序扫描 Vega 时，它没有再次列出相同的问题，我相信这使我的 Web 应用程序免受 CSRF 攻击。

现在，阅读 this 后发布后，我正在考虑 request.getHeader("Origin") 如何防止 跨站请求伪造攻击，无论来源是 https://webapp.com或https://evil.com ，请求对于应用程序始终有效，因为我从请求 header 本身中选择“Access-Control-Allow-Origin”。

任何人都可以帮助我理解这个概念，如何设置 request.getHeader("Origin") 来避免 CSRF 攻击？

谢谢。

阅读@rism 答案和 Patrick Grimard 后理解 post :

当客户端应用程序发出 AJAX 请求时，浏览器首先向服务器发送预检 OPTIONS 请求，以确定允许客户端对 GET 以外的请求执行哪些操作> 这就是我们应该将 Access-Control-Allow-Origin 设置为源或特定域作为响应 header 的一部分的原因。

以POST为例，当客户端发送请求时，浏览器首先向服务器发出预检OPTIONS请求，服务器响应OPTIONS > 请求包含指示浏览器允许所有origin 请求的 header 。除了添加 response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin")); 网站仍然容易受到攻击，因此我们需要显式白名单 IP 要么在 Apache 中(对于部署在集群中的应用程序)，如 here 所示或在 Tomcat 中，如所述 here .

我仍然有一个疑问，如果我们在服务器级别本身限制 IP 地址，那么我们真的需要设置“Access-Control-Allow-Origin”作为响应 header 的一部分？

Answer 1

它有助于理解 CSRF 攻击的目的。它们并不是要“窃取”您的数据。顾名思义，它们是关于“跨站点伪造请求”，又名跨站点请求伪造，又名 CSRF。

目的是通过涉及银行帐户的规范示例来更改服务器上的状态。通过 CSRF 攻击，我们试图以您的名义伪造一个请求(转账 100 美元)。

所以简单的例子是攻击者将脚本或隐藏表单等注入(inject)到任何站点的页面中，例如www.cutekittens.com 并让该脚本针对特定站点，例如www.mybank.com 因此称为“跨站点”。

这个想法是，作为受害者，您将同时登录两个站点，而银行站点的安全性很松懈。当您在 www.cutekittens.com 上查看可爱的小猫时，攻击者已将跨站点攻击脚本注入(inject)其中的一个或多个页面。该脚本的目的是代表您向您的银行 www.mybank.com 提出转账 100 美元的请求。

这里再次注意，攻击者并没有窃取您的数据，而是试图以您的名义发出伪造的请求来窃取您的金钱/其他内容。这不是中间人攻击 (MITM)，而是请求伪造攻击。在 CSRF 中，攻击者不会看到也不需要看到您的数据，他们只是想办法表现得就像您一样。其后续目的可能是获取您的数据，例如更改您的密码等，但攻击本身是关于发出伪造的请求，而不是拦截。

因此，银行保护自身及其客户安全的一种方法是明确说明哪些网站可以或不可以通过 CORS header 向其发出请求。

如果它们没有明确包含 www.cutekittens.com，那么即使攻击者设法将其恶意脚本注入(inject) www.cutekittens.com 网站上的页面，并且即使您碰巧同时浏览两个 Cutekittens和您的银行站点相同，即使执行攻击脚本，对 www.yourbank.com 的请求也会被丢弃(在 POST 预检之后)，因为银行尚未向浏览器发送 header ACCESS-CONTROL-ALLOW-ORIGIN :www.cutekittens.com专门授权请求。

所以你是对的。通过用动态 request.getHeader("Origin") 替换此 header 的静态 * 值，您所做的一切就是让 Vega 摆脱您的困扰。如果您的网站编写得不好，则仍然可能容易受到此攻击，因为它会反射回 www.cutekittens.com，这可能不是您想要的。

您使用 request.getHeader("Origin") 而不是 * 的原因之一是您想要将凭据发送到服务器。您无法发送凭据，例如CORS AJAX 请求上的 cookies 等，仅使用 * 发送到服务器，因此在这种情况下，您将动态地将源反射回客户端。

但是通过这样做，您确实需要确保以其他方式降低风险。在这种情况下，您通常还会将您将反射(reflect)和不会反射(reflect)的内容列入白名单。例如Portal.mybank.com 可能会在列表中，但 www.cutekittens.com 不会。因此，如果您要使用动态源反射，这将是您可以实现的下一步。