blocks|key|520257|text|是的，在使用承载方案身份验证时，不需要CSRF保护，因为浏览器不会自动将授权头添加到请求中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|520258|您确实需要对cookie、basic、Windows、摘要和客户端证书身份验证方案进行CSRF保护，因为这些都是由浏览器自动添加的。|520259|还请参阅Dominick关于隐式身份验证与显式身份验证的文章：http://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/|offset|length|520260|entityMap|0|LINK|mutability|MUTABLE|url|http://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/^0|0|0|V|2V|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Yes, you don't need CSRF protection when using a bearer scheme authentication as the browser does not automatically add the Authorization header to the request.

You do need CSRF protection for cookies, basic, Windows, digest and client certificates authentication schemes as these are automatically added by the browser.

See also Dominick Baier's article on implicit vs explicit authentication: <a href="http://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/" rel="noreferrer">http://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/</a>

blocks|key|672555|text|理论上，你不需要像你所描述的那样保护CSRF。但是我主要关心的问题之一是在哪里存储访问令牌。浏览器的本地存储不能提供良好的安全性。所以它经常储存在饼干里。因此，CSRF漏洞又回来了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|672556|在他的文章中描述了一种防止访问令牌从CSRF和被XSS窃取的双cookie机制。|offset|length|672557|总结这篇文章:访问令牌的有效负载存储在JavaScript可访问的cookie中。访问令牌的签名存储在JavaScript无法访问的cookie中。客户端从cookie中读取有效负载，并将其在身份验证头中传递给服务器。服务器根据在HttpOnly+cookie中发送的签名验证令牌。|672558|因此，它的CSRF-保存和攻击者不能通过XSS窃取整个令牌，因为没有JS-访问签名。|672559|编辑：|style|BOLD|672560|同时，现代浏览器支持SameSite+cookie性质。如果将此属性设置为Strict，则只有当当前站点等于cookie的起源时，cookie才会发送到服务器。|CODE|672561|entityMap|0|LINK|mutability|MUTABLE|url|https://jcbaey.com/authentication-in-spa-reactjs-and-vuejs-the-right-way|1|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite^0|0|3|2|0|0|0|0|0|3|0|A|8|11|6|J|8|1|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@$D|12|E|13|1|14]]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@$D|18|E|19|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1A|8|@$D|1B|E|1C|L|P]|$D|1D|E|1E|L|P]]|9|@$D|1F|E|1G|1|1H]]|A|$]]|$1|Q|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]|Y|$5|T|U|V|A|$W|Z]]]]

Theoretically, you don´t need CSRF protection as you described. But one of my main concerns is where to store the access token. The local storage of the browser does not provide a good security. So it´s often stored in cookies. And so, the CSRF vulnerability comes back.
Jean-Christophe Baey described in his <a href="https://jcbaey.com/authentication-in-spa-reactjs-and-vuejs-the-right-way" rel="nofollow noreferrer">article</a> a two-cookie mechanism to prevent access tokens from CSRF and from being stolen by XSS.
To sum that article up: The payload of the access token is stored in a cookie that is accessibly by JavaScript. The signature of the access token is stored in a cookie that is NOT accessible by JavaScript.
The client reads the payload from the cookie and passes it in the Authentication-Header to the server. The server validates the token based on the signature which is sent in the HttpOnly cookie.
So, its CSRF-save and an attacker cannot steal the entire token via XSS because there is no JS-access to the signature.
Edit:
In the meantime, modern browsers support the <code>SameSite</code> <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite" rel="nofollow noreferrer">cookie property</a>. If you set this property to <code>Strict</code>, the cookie will only be sent to the server if the current site is equals to the origin of the cookie.

I understood the purpose of the CSRF Token protection.

However, I think this protection is useless and we should remove it in the case of a REST API requiring an authentication token in the header for each action.

This way, even if Mallory forges a malicious HTML link to Alice, the attack can not be done. The reason is that:

Alice keeps her authentication information in a header key that Mallory don't know. And unlike a cookie, Alice's browser doesn't submit this authentication token automatically.

So in this context, I would like to have you point of view about the question: can we remove a CSRF token protection from this kind of API design?

CSRF Token in REST API with authentication

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我理解CSRF令牌保护的目的。但是，我认为这种保护是无用的，如果REST 要求在每个操作的头中使用身份验证令牌，我们应该删除它。这样，即使Mallory伪造了到Alice的恶意HTML链接，攻击也无法完成。原因是：Alice将身份验证信息保存在Mallory不知道的头密钥中。与cookie不同，Alice的浏览器不会自...

问REST中具有身份验证的CSRF令牌
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST中具有身份验证的CSRF令牌EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST中具有身份验证的CSRF令牌
EN