让我们说，我们在domain 示例的nginx为我们提供了一个水疗中心，还有一个位于 api.example.com 的REST API。
水疗和API之间的身份验证通过JWT进行。 Spa在 localstorage 中存储的短暂寿命（15分钟）访问权限，并且服务器在HTTPonly cookie上设置了更长的寿命（天）刷新。服务器上允许CORS用于域 example.com 。
问题1 ：
我昨天与一位同事讨论了这一点，他们相信，由于我的刷新代币居住在cookie中，所以我需要CSRF保护我的应用程序。我不同意帐户，即刷新token不能用于“访问”任何私人资源，并且只能在 get 请求时由服务器检查到特定的终点，以展示令牌与水疗中心的交换机制。
Q1。
这是正确的吗？有什么方法可以恶意剥削Httponly Cookie中的刷新？
问题2 ：
进一步思考这个问题，即使我们要去一些CSRF保护，如果一无所有，那也是如此。首先，您将如何将令牌发送到客户端？我们不使用表单并将UI完全渲染在客户端上，因此隐藏的字段不可能解决，索引文件由Nginx提供，因此我们也无法在HTML上嵌入元标记。
Q2。是否有任何方法可以使CSRF保护在单页应用程序中起作用？
Let us say we have an SPA being served by nginx at domain example.com and a REST API hosted at api.example.com.
Authentication between the SPA and the API happens through a JWTs. A short lived (15 min) access-token that is stored by the SPA in localstorage and a longer lived (days) refresh-token that is set by the server on an HttpOnly cookie. CORS is permitted on the server for the domain example.com.
Problem 1:
I was discussing this yesterday with a colleague and they believe that because my refresh token resides in a cookie, I require CSRF protection for my application. I disagreed on the account that the refresh-token can not be used to "access" any private resource and is only checked for by the server during a GET request to a specific end-point which exposes the token exchange mechanism to the SPA.
Q1.
Is this reasoning correct? Is there any way that a refresh-token in an HttpOnly cookie be exploited maliciously?
Problem 2:
Thinking further on the subject, even if we were to go for some CSRF protection, if for nothing then peace-of-mind. How would you go about sending the token to the client in the first place? We do not use forms and render the UI completely on the client so a hidden field is out of the question, the index file is served by nginx so we can not embed a meta tag on the HTML either.
Q2. Is there any way to make CSRF protection work for a Single Page Application?
发布评论
评论（1）
我相信将刷新令牌放在cookie中是可以的。只需确保cookie只能发送到负责刷新的一个端点，并满足其他cookie保护要求，如oWASP应用程序安全验证标准在这里。
如果有人通过CSRF攻击您，可能会发生什么最糟糕的事情？他可能会强迫您刷新令牌。但是，代币不会以任何方式暴露给攻击者，因此不会发生泄漏。
如果这样做，您将被迫解决CSRF问题，也请看一下：
I believe holding the refresh token in a cookie is ok. Just make sure the cookie may be sent only to the one endpoint responsible for the refresh and fulfill other cookie protection requirements as mentioned in V3.4 of the OWASP Application Security Verification Standard available here.
What is the worst thing that may happen if someone attacks you over CSRF then? He may force you to refresh the token. But the token will not be exposed by any means to the attacker, so no leakage will take place.
If despite this you will be forced to tackle the CSRF problem, have a look at this too: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html