如何请求。getHeader（“来源”）防止跨站点请求伪造攻击？

Question

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

然后我下载了Vega并快速扫描了我的webapp，发现了一个VAPT问题，如下所示：

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

然后我开始寻找一个解决方案来修复它，并遇到了这篇文章，并实现了一个过滤器，正如答案中建议的那样：

@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攻击。

现在，看完这篇文章后，我在思考如何请求。getHeader（“Origin”）防止跨站点请求伪造攻击，因为无论源是什么https://webapp.com或https://evil.com，请求对应用程序始终有效，因为我正在从请求标头本身选择“访问控制允许来源”。

有人能帮助我理解这个概念吗，如何设置request.getHeader（"Origin"）从CSRF攻击中保存？

谢谢

阅读@rism answer和Patrick Grimard post后理解：

当客户端应用程序发出AJAX请求时，浏览器首先向服务器发送预飞行OPTIONS请求，以确定客户端被允许做什么，对于GET以外的请求，这就是我们应该设置访问控制的原因-允许-起源作为响应头的一部分起源或特定域。

以POST为例，当客户端发送请求时，浏览器首先向服务器发出飞行前OPTIONS请求，服务器对OPTIONS请求的响应包含指示浏览器允许所有origin请求的标题。除了添加响应。setHeader（“访问控制允许原点”，request.getHeader（“原点”）站点仍然易受攻击，因此我们需要在Apache（对于部署在集群中的应用程序）中明确地白名单IP，如这里所述，或者在Tomcat中，如这里所述。

我仍然有一个疑问，如果我们限制服务端本身的IP地址，那么我们真的需要设置访问-控制-允许-起源作为响应头的一部分吗？

Answer 1

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

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

所以简单的例子是攻击者将脚本或隐藏表单等注入到任何站点的页面中，例如www.cutekittens.com并使该脚本针对特定站点，例如www.mybank.com术语跨站点。

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

请再次注意，攻击者并没有窃取您的数据，而是试图以您的名义伪造请求来窃取您的钱/任何东西。这不是中人攻击（MITM），这是请求伪造攻击。在CSRF中，攻击者看不到或不需要看到你的数据，他们只是想办法表现得好像他们是你。这样做的后续目的可能是获取您的数据，例如更改密码等，但攻击本身是为了伪造请求，而不是拦截。

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

如果他们没有特别包括www.cutekittens。com，即使攻击者设法将其恶意脚本注入www.cutekittens上的页面。com网站，即使您碰巧同时在cutekittens和您的银行网站上冲浪，即使执行了攻击脚本，也会将请求发送到www.yourbank。com将被删除（在帖子飞行前），因为银行没有向浏览器ACCESS-CONTROL-ALLOW-ORIGIN:www.cutekittens发送标题。com专门授权该请求。

所以你是对的。您所做的一切都是将此头的静态*值替换为动态请求。getHeader（“Origin”）就是让Vega离开你的背。如果您的网站写得不好，它仍然可能容易受到此攻击，因为它会反映www.cutekittens。这大概不是你想要的。

使用request.getHeader（Origin）而不是*的一个原因是当您要向服务器发送凭据时。您不能仅使用*向服务器发送CORS AJAX请求中的凭据（例如cookie等），因此在这种情况下，您将动态地将来源反映回客户端。

但通过这样做，你真的需要确保你正在以其他方式降低风险。在这种情况下，您通常也会将您将要反映和不会反映的内容列为白名单。e、 g.门户网站。我的银行。com可能在名单上，但www.cutekittens。com不会。如果要使用动态原点反射，那么这将是您可以实现的下一步。