$https请求的安全性

当您研究Web应用程序安全性时，您会遇到跨站点请求伪造(CSRF(。这种攻击媒介正在利用 cookie，但以一种可预防的方式。

大多数攻击都集中在窃取您的 cookie 上，因为几乎每个网站都使用 cookie 作为身份验证形式。设置是这样的：当用户登录到您的服务器时，您在浏览器中设置一个cookie。此 Cookie 包含一个唯一 ID，该 ID 是指向数据库中用户会话信息的链接。浏览器在将来的请求中提供此cookie，服务器知道您是谁。

从表面上看，这听起来还不错，但这里有一个问题：即使最终用户没有自己执行该操作，Web浏览器也可能被欺骗向您的服务器发出请求。

使用 POST 请求

有时人们认为使用正确的基于表单的 POST 请求可以缓解这种攻击，但事实并非如此。

使用仅限 HTTP 或安全 Cookie

虽然您绝对应该在会话 cookie 上使用这些标志，但它们不会隐含地阻止攻击：当向您的域发出请求时，浏览器仍会将 cookie 发送到您的域。您的服务器不知道这是真实用户还是攻击。

如何预防企业社会责任

您可以通过依赖浏览器遵循的一组规则(称为同源策略(来实现此目的。本政策断言某些敏感操作是由在我们网站上运行的 JavaScript 代码执行的，而不是由其他网站执行的。

Angular 打包了 CSRF 代币方法，使我们更容易实现。对于 Angular 应用程序对服务器发出的每个请求，Angular $http 服务将自动执行以下操作：

在当前域上查找名为XSRF-TOKEN的cookie。如果找到该 cookie，它将读取该值并将其作为 X-XSRF-TOKEN 标头添加到请求中。

因此，客户端实现会自动为您处理！但这确实将服务器端的部件留在您手中。您将需要执行以下部分：

登录期间：创建 CSRF 令牌(使用随机的、不可猜测的字符串(，并将其与用户会话关联。您需要在登录响应中将其作为XSRF-TOKEN cookie发送。断言对 API 的所有传入请求都具有 X-XSRF-TOKEN 标头，并且标头的值是与用户会话关联的令牌。

就是这样！通过一些后端工作，您现在有一个保护您免受CSRF攻击的策略。

您将在此处找到如何防止CSRF攻击的工作示例对于理解CSRF攻击的理论，请遵循此参考