自定义 HTTP 标头或 cookie？自定义身份验证/授权如何在 CSRF 中提供帮助？答案

【问题标题】：Custom HTTP Header or cookies? how custom authentication/authorization helps in CSRF?自定义 HTTP 标头或 cookie？自定义身份验证/授权如何在 CSRF 中提供帮助？
【发布时间】：2020-01-11 19:01:18
【问题描述】：

如果有人可以帮助我了解自定义 HTTP 授权标头如何帮助保护 CSRF 攻击。
如果我错了也请纠正我，它是否也可以防止使用 fiddler 进行重放攻击？

提前感谢您的帮助

【问题讨论】：

这应该在security.stackexchange.com上询问。
确定有什么方法可以移动它或者我需要在那里发布一个不同的问题吗？

标签： javascript http csrf

【解决方案1】：

当身份验证基于 cookie 时，来自客户端的每个触发请求都将被验证。无论是“好” - 由应用程序设计，还是“坏” - 由于 CSRF 攻击。浏览器将始终盲目向每个请求添加 cookie。例如，当身份验证基于承载时附加到“Authenticate”标头的令牌，客户端可以决定在哪种情况下发送经过身份验证的请求以及在哪种情况下保持匿名。

但是，这并不意味着您不能使用 Fiddler 等工具拦截请求、从 HTTP 标头中获取令牌并从同一工具执行经过身份验证的请求。

【讨论】：

那么仅使用基于自定义 http 标头的令牌与基于 cookie 的身份验证有什么区别？还是有同样的问题对吗？
同样，如果是 HTTP 标头，客户端可以控制请求何时通过身份验证，何时不通过身份验证。这可以防止某些类型的攻击，另一方面这会引入其他问题，例如，客户端有责任存储身份验证令牌。
我可以从 java 脚本访问这些自定义标头吗？
这里是一个使用 jQuery 的例子：$.ajax('/api/some', : { 'Authenticate': 'Bearer: some_token_here' }});
我仍然错过了这一点，例如浏览器是否在每个请求中重复 cookie 并且可以通过 javascript 访问。自定义标头也可以做到这一点，所以它只是为某人提供了一个变量来弄清楚做 CSRF 吗？或者更多的东西。如果这些自定义标头对 JavaScript 不可用，那么有人无法执行和窃取我的自定义标头，这可以轻松地进行 cookie 操作？