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

Question

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

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

Vega检测到资源设置了不安全的Cross-Origin资源共享(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() {
    }
}

现在，当我再次扫描Vega对抗webapp时，它没有再次列出相同的问题，我相信这挽救了我的webapp对抗CSRF攻击。

现在，在阅读这篇文章后，我正在思考request.getHeader("Origin")如何阻止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在Apache中(对于部署在集群中的应用程序)，如这里所做的或在Tomcat中，如这里所述。

我仍然有一个疑问，如果我们限制IP地址在服务器级别本身比我们真的需要设置"Access-Control-Allow-Origin"作为响应头的一部分吗?

Answer 1

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

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

所以简单的例子是攻击者注入一个脚本或一个隐藏的表单等到any site例如www.cutekittens.com的页面，并有该脚本的目标specific site例如www.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的请求将被删除(在起飞前的一个帖子),因为银行没有发送的头到浏览器ACCESS-CONTROL-ALLOW-ORIGIN : www.cutekittens.com特别授权请求。

所以你是对的。通过用动态request.getHeader("Origin")替换此头的静态*值，您所做的一切都是让Vega离开您的背部。如果你的网站写得不好，你的网站仍然有可能受到这种攻击，因为它会反射回www.cutekittens.com，这可能不是你想要的。

使用request.getHeader("Origin")而不是*的一个原因是当您想要向服务器发送凭据时。你不能在CORS AJAX请求上发送凭据，例如cookies等，只使用*，所以在这种情况下，你会动态地将源反射回客户端。

但是通过这样做，你真的需要确保你在其他方面降低了风险。在这种情况下，你通常也会列出你会和不会反射的东西。例如，portal.mybank.com可能在列表中，但www.cutekittens.com不在。这是你下一步可以实现的，如果你要使用动态原点反射