如何request.getHeader（“ Origin”）防止跨站点请求伪造攻击？

Question

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

然后，我下载了Vega，并迅速扫描了我的Web应用程序，并遇到了VAPT问题，如下所示：

Vega检测到资源已设置了不安全的跨域资源共享（CORS）访问控制。CORS提供了允许服务器限制跨站点请求对某些受信任域的资源访问的机制。通过将“ Access-Control-Allow-Origin”响应标头的值设置为通配符值，所讨论的服务器已允许来自任何来源的资源。这带来了安全风险，因为任何站点都可以发出访问资源的请求，而不论其来源如何。

然后，我开始寻找解决方案来解决它，并发现这篇文章并filter按照答案中的建议实施了以下内容：

@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() {
    }
}

现在，当我再次针对Webapp扫描Vega时，它不再列出相同的问题，我相信这使我的Webapp免受了CSRF攻击。

现在，在阅读了这篇文章之后，我正在考虑如何request.getHeader("Origin")防止from Cross Site Request Forgery attacks，因为无论源是https://webapp.com还是https://evil.com，当我"Access-Control-Allow-Origin"从请求中选择请求时，请求始终对应用程序有效标头本身。

谁能帮助我理解这个概念，以及如何设置request.getHeader("Origin")节省CSRF attacks？

谢谢。

阅读@rism答案和Patrick Grimard 帖子后的理解：

当客户端应用程序发出AJAX请求时，浏览器最初会向OPTIONS服务器发送预检请求，以确定允许客户端执行除其他请求以外的其他操作，GET这就是我们应将Access-Control-Allow-Origin源域或特定域设置为响应标头的原因。

以的示例为例POST，当客户端发送请求时，浏览器首先OPTIONS向服务器发出预检请求，并且服务器对OPTIONS请求的响应包含标头，这些标头指示浏览器origin允许所有请求。除了增加response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));网站仍然是脆弱的，所以我们需要明确whitelist的IP的无论是在阿帕奇（应用程序部署在集群）为完成这里所描述的或在Tomcat中这里。

我仍然有一个疑问，如果我们要在服务器级别本身限制IP地址，那么我们真的需要将其设置"Access-Control-Allow-Origin"为响应标头吗？

Answer 1

它有助于了解CSRF攻击的目的。它们不是要“窃取”您的数据。顾名思义，它们是关于“跨站点提出伪造的请求”（又称为“跨站点伪造”或CSRF）。

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

因此，简单的例子就是攻击者在any sitewww.cutekittens.com 上的页面中注入脚本或隐藏形式等，并使该脚本针对specific sitewww.mybank.com等术语Cross Site。

这样做的想法是，作为受害者的您将同时登录两个站点，银行站点的安全性不高。当您在www.cutekittens.com上看到可爱的小猫时，攻击者已将跨站点攻击脚本注入了其中的一个或多个页面。该脚本的目的是代表您向银行（www.mybank.com）提出100美元的汇款请求。

再次提醒您，攻击者不是在窃取您的数据，而是试图以您的名义提出伪造的请求，以窃取您的金钱/其他。这不是man in the middle攻击（MITM），它是请求伪造攻击。在CSRF中，攻击者看不到或不需要查看您的数据，他们只是找到一种方式来像对待您一样。这样做的后续目的可能是获取您的数据，例如更改密码等，但是攻击本身的目的是提出伪造的请求，而不是拦截。

因此，银行确保自己和客户安全的一种方法是通过具体说明哪些站点可以通过CORS标题，也可以不通过标题向其发出请求。

而且，如果攻击者没有专门包含www.cutekittens.com，即使攻击者设法将其恶意脚本注入到www.cutekittens.com网站上的页面中，即使您碰巧同时浏览了cutekittens和您的银行站点，并且即使执行了攻击脚本，对www.yourbank.com的请求也将被丢弃（在进行POST预检后），因为银行尚未向浏览器发送标头来ACCESS-CONTROL-ALLOW-ORIGIN : www.cutekittens.com专门授权该请求。

所以你是对的。通过将*标头的静态值替换为动态值，您所要做的request.getHeader("Origin")就是让Vega摆脱困境。如果您的网站写得不好，可能仍然容易受到此攻击的影响，因为它会反映回www.cutekittens.com，这大概不是您想要的。

使用request.getHeader("Origin")代替的原因之一*是当您要将凭据发送到服务器时。您不能仅使用CORS AJAX请求将凭据（例如cookie等）发送到服务器*，因此在这种情况下，您会将源动态地反射回客户端。

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