CSRF、CORS 和我的身份验证方法
我看到了很多关于 CSRF 攻击和 GET 请求的问题，我正在尝试找出我的应用程序的身份验证系统需要什么。
我的堆栈是托管在 app.site.com 上的 SPA React 应用程序和位于 api.site.com 上的 API。
我的计划是执行以下操作。
- 加载时，React 应用程序将调用服务器上的 GET 路由来获取当前用户。
- 该路由将检查 cookie，查找具有有效令牌的 httpOnly cookie，如果是，则发回登录令牌，该令牌将存储在应用程序内存中。
- 然后，每个后续请求都将检查这两个令牌，以便成功。
我认为其中的一个潜在缺陷如下： 攻击者能否将受害者发送到 www.other-domain.com，这将触发一个调用脚本我的 /user 端点？这将发送 httpOnly cookie，因此错误的站点/脚本现在将取回我的应用程序内存令牌，然后理论上可以发送其他请求。我知道我可以用这个来防止 CORS，但这就足够了吗？
我读到 CSRF 是一种“只写”攻击，但在这种情况下，我可以看到这可能是 GET 请求上的问题。
那么，我的问题是：
- 从安全角度来看，上述设置是否可行？
- 对 httponly cookie 使用 SameSite Cookie 是否会消除对应用程序内存令牌的需要？
- 在这个过程中有什么我遗漏的地方吗？
我做了很多研究，但很想听听更有经验的工程师的想法。预先感谢您提供的任何帮助。
I've seen many questions about CSRF attacks and GET requests, and I'm trying to work out what I need for my app's authentication system.
My stack is an SPA React app hosted at app.site.com, and an API at api.site.com.
My plan is to do the following.
- On load, the React app will call a GET route on the server to get the current user.
- This route will check the cookies, look for an httpOnly cookie with a valid token, and if so, send back a loggedin token which will be stored in application memory.
- Each subsequent request will then be checked for both tokens in order to succeed.
A potential flaw in this that I can see is as follows:
Could an attacker send a victim to www.other-domain.com, which will trigger a script that calls my /user endpoint? That would send the httpOnly cookie, so the bad site/script will now get back my application memory token, and could then theoretically send other requests. I know I can protect against CORS with this, but is that enough?
I've read that CSRF is a 'write-only' attack, but in this instance I can see that it could be a problem on a GET request.
My questions, then, are:
- Is the setup above workable from a security standpoint?
- Would using a samesite cookie for the httponly cookie negate the need for the application memory token?
- Are there any points in this process that I'm missing?
I've done a lot of research, but would love to hear the thoughts of more experienced engineers. Thank you in advance for any help you can provide.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，你是对的。 CSRF 可用于在服务器上执行
create或delete操作（或任何其他副作用） - 这也可能发生在上，具体取决于您的服务器实现GET请求。在某些极少数情况下，CSRF 也可用于 DoS（拒绝服务），例如，当您的 API 中有非常昂贵的服务器端计算时，它可能很容易被触发，并且经常通过 CSRF 触发。您需要 CORS 才能使您的方案发挥作用（app.site.com 上的 SPA 和 api.site.com 上的 API）。如果可能的话，我会尽量避免使用 CORS，因为
1.如果配置不当，它可能会引入安全问题，2.当浏览器打开时，它可能会对性能产生负面影响运行预检请求，这实际上会使往返时间加倍，并且3.您在 SPA 和 API 之间引入了紧密耦合。这就是 BFF（后端前端）派上用场的地方：您只需使用
app.site.com/api从 SPA 进行 API 调用，并且您的app.site.comcode> 服务器将充当代理并将这些请求转发到api.site.com。现在您根本不需要 CORS，并且解耦了 SPA 和 API，因为现在您可以在 BFF 级别拦截 API 调用并转换对 API 发出的请求，还可以转换响应、聚合数据、组合多个 API请求等
In general you're right. CSRF can be used to execute a
createordeleteaction (or any other side effect) on the server - which depending on your server implementation can also happen with aGETrequest. In some rare cases CSRF can also be used for DoS (Denial-of-Service), for example when you have a very expensive server-side computation in your API, that can be triggered too easy and often via CSRF.You would need CORS for your scenario to work (SPA on app.site.com and API on api.site.com). I'd try to avoid using CORS if possible, because
1.it can introduce security problems if configured poorly,2.it can have a negative impact on performance when the browser runs preflight requests, which effectively will double the roundtrip time, and3.you introduce tight coupling between your SPA and your API.And that's where BFF (backend for frontend) comes in handy: You simply use
app.site.com/apifor your API calls from your SPA, and yourapp.site.comserver will act as a proxy and forward these requests toapi.site.com.Now you don't need CORS at all, and you decoupled your SPA and API, because now you can intercept your API calls at the BFF level and transform the requests made to the API and also transform the responses, aggregate data, combine multiple API requests, etc.