api存在csrf攻击吗_使用rest api防止单页应用上的csrf攻击

api存在csrf攻击吗

tl;dr — If your SPA uses a private REST API, use CORS and a CSRF Token header. If your SPA uses a public REST API, use a SameSite Strict cookie for mutating operations (if you only support newer browsers) or separate API security domains (if you support older browsers as well); public API clients just use OAuth Bearer tokens.

tl; dr —如果您的SPA使用私有REST API，请使用CORS和CSRF令牌标头。 如果您的SPA使用公共REST API，请使用SameSite Strict cookie进行操作更改(如果您仅支持更新的浏览器)或单独的API安全域(如果您也支持旧的浏览器)； 公共API客户端仅使用OAuth Bearer令牌。

The world of web app security is a strange place. It’s a bit like playing whack-a-mole, because one security measure may often introduce a new security hole.

Web应用程序安全性的世界很奇怪。 这有点像打w子，因为一种安全措施可能经常会引入一个新的安全漏洞。

This post walks through the CSRF-vulnerability analysis I did recently for my company, and the thinking that went behind it. In particular, we wanted to ensure that our React-based app is secure from CSRF attacks, even though the backend REST API doesn’t require CSRF tokens.

这篇文章介绍了我最近为公司所做的CSRF漏洞分析以及其背后的想法。 特别是，即使后端REST API不需要CSRF令牌，我们也要确保基于React的应用程序免受CSRF攻击。

CSRF (CSRF)

Let’s start with Cross Site Request Forgery (CSRF). This is when a malicious website is able to perform actions on your web app within the context of a logged-in user. This happens because your browser helpfully sends your auth credentials along with the request, which is how the site knows that you’re still logged in. Most of the time, this is an HTTP cookie, but you can also be susceptible with any user agent -managed credentials (such as HTTP basic auth, HTTP digest auth, or even mTLS).

让我们从跨站点请求伪造 (CSRF)开始。 这是指恶意网站能够在已登录用户的上下文中对您的Web应用程序执行操作的情况。 发生这种情况是因为您的浏览器会帮助您将身份验证凭据与请求一起发送，这是网站知道您仍在登录的方式。大多数情况下，这是一个HTTP cookie，但是您也容易受到任何用户代理的影响管理的凭据(例如HTTP基本身份验证，HTTP摘要身份验证，甚至是mTLS)。

How do you prevent this? Your first stop when dealing with any web app security should be OWASP; sure enough, they have a whole guide to CSRF prevention. The traditional mitigation involves generating a CSRF token on the server and added as a hidden form field during server-side rendering.

您如何防止这种情况？ 处理任何Web应用程序安全性的第一站应该是OWASP； 的确，他们有CSRF预防的完整指南 。 传统的缓解措施包括在服务器上生成CSRF令牌，并在服务器端渲染期间将其添加为隐藏表单字段。

But how does this work for a modern web development stack, where you have a javascript “Single Page App” (SPA) frontend backed by a REST API?

但是，对于具有REST API支持的javascript“单页应用”(SPA)前端的现代Web开发堆栈，这如何工作？

On its face, the easiest way to prevent CSRF is to not use cookies to store your auth. No cookies, no CSRF. However, this just opens up a new problem- where do you store your auth now? The most obvious second choice is to use local storage. However, this exposes your web app to Cross Site Scripting attacks (XSS), and is thus not recommended.

从表面上看，防止CSRF的最简单方法是不使用cookie来存储您的身份验证。 没有Cookie，没有CSRF。 但是，这只是一个新问题-您现在将身份验证存储在哪里？ 第二种最明显的选择是使用本地存储。 但是，这会使您的Web应用程序遭受跨站点脚本攻击(XSS)，因此不建议这样做。

XSS (XSS)

Cross Site Scripting (XSS) is one of the most common and most dangerous attacks online. This effectively enables an attacker to coerce your website to run arbitrary code, usually JavaScript, in the context of another logged-in user.