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

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

VAPT

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

@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检测到资源设置了不安全的交叉源 资源共享（CORS）访问控制。CORS提供了以下机制： 允许服务器将跨站点请求的资源访问限制为 某些受信任的域。有问题的服务器已允许使用资源 通过设置 “Access Control Allow Origin”响应头指向通配符值。 这会带来安全风险，因为任何站点都可以向 访问资源，无论其来源如何

然后我开始寻找一个解决方案来修复它，遇到了post，并实现了一个

过滤器

，如下所示：

@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”）

如何防止

跨站点请求伪造攻击

，因为无论源代码是或是什么，当我从请求头本身选择

“访问控制允许源代码”

时，请求对应用程序始终有效

有人能帮助我理解这个概念吗？设置

请求。getHeader（“Origin”）

如何从

CSRF攻击中保存

谢谢

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

当客户端应用程序发出AJAX请求时，浏览器首先向服务器发送飞行前
OPTIONS
请求，以确定允许客户端执行的操作，对于非
GET
的请求，这就是我们应该将
Access Control Allow Origin
设置为响应头的一部分，即允许源站或特定域

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

我仍然有一个疑问，如果我们在服务器级别本身限制IP地址，那么我们真的需要将
“访问控制允许来源”
设置为响应头的一部分吗？
这有助于理解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
发送标题以明确授权该请求

所以你是对的。你所做的就是用动态的请求替换这个头的静态值。如果您的网站写得不好，那么它仍然可能容易受到此攻击，因为它会反映www.cutekittens.com，这可能不是您想要的

使用
request.getHeader（“Origin”）
而不是
*
的一个原因是，您希望向服务器发送凭据。您不能仅使用
*
将CORS AJAX请求上的凭据（如cookies等）发送到服务器，因此在这种情况下，您将动态地将源代码反映回客户端

但通过这样做，你真的需要确保你正在以其他方式降低风险。在这种情况下，您可能会出现als