通过AJAX获取CSRF令牌

Question

我打算构建一个具有解耦前端和后端（仅使用ajax请求）的应用程序。我不允许跨站点ajax请求。我可以生成一个Ajax调用一个CSRF令牌，通过添加像/ CSRF的API，返回是这样的：{CSRF：“令牌”}下面的网站说，我绝对不能这样做：https://github.com/pillarjs/understanding-csrf

确保CSRF令牌无法通过AJAX访问！不要为获取令牌而创建/ csrf路由，特别是不支持该路由上的CORS！

为什么有特定的原因？我理解CORS背后的原因 - 这是被禁用的，但是通过ajax提供csrf令牌是否存在固有的安全风险？

Answer 1

他们把解释放在前一段中的同一页中。

攻击者必须以某种方式从您的站点获取CSRF令牌， 并且他们必须使用JavaScript来执行此操作。因此，如果您的站点 不支持CORS，那么攻击者无法获取CSRF令牌，从而消除威胁。

如果您将CSRF令牌暴露给AJAX，那么攻击者更容易获取该令牌，然后在其他请求中使用该令牌。

Answer 2

这不是一个安全隐患，这里的原因：

为什么你会，你甚至要公开CSRF通过AJAX令牌？

从可用性的角度来看，如果您没有提供通过AJAX获取CSRF令牌的方法，那么您的网站可能会很糟糕，因为任何有多个选项卡打开的人都会遇到关于不匹配的错误CSRF令牌。

在使用CSRF令牌的网站上，如果您在提交POST请求之前获取最新CSRF令牌的表单钩子，那么对于用户来说这是一个更好的体验。

现代单页应用程序网站（例如，使用React或Angular构建的通用网站）也需要一种轻松获取CSRF令牌的方法，它可以像CSRF令牌的投影一样受益，就像传统的仅由服务器呈现的网站一样。

CSRF令牌绑定到会话

CSRF令牌绑定到会话 - 即使你没有明确登录，它仍然需要依赖于客户端和服务器之间跟踪会话。 如果您的会话令牌具有HTTP Only cookie（这是最佳做法，并防止XSS攻击窃取它并帮助保护您免受CSRF攻击），但没有人能通过远程域从请求中读取您的CSRF令牌（即使浏览器不执行CORS！）。

跨来源资源共享

CORS位来跌宕很多类似这样的讨论，但它实际上是一个有点红鲱鱼。

安全性实际上归结为对您的sesison cookie使用HTTP Only cookie，并且使用会话令牌为cookie添加相同的域策略 - 自从时间曙光以来，所有浏览器都支持该策略（使用边缘案例警告MSIE将cookie暴露给其他浏览器不支持的子域）。

如果远程站点上的某些JavaScript无法读取会话令牌 - 如果它位于域中的HTTP Only cookie中，则无法读取它 - 那么它无法读取您的CSRF令牌！

如果使用HTTP只有cookie和CSRF令牌可以抵御CSRF和XSS攻击？

您应该从CSRF攻击中获得安全，并且对某些类型的XSS攻击的防护能力有限，但XSS仍然存在风险。

如果有人发现一种方法来使用XSS在您的网站上执行任意JavaScript并创建来自您的域的请求，那么无论是CSRF，HTTP仅Cookie还是会话指纹都将保护您 - 此时可执行的任何操作看起来就像它是由用户触发的。

对请求使用CAPTCHA将提供一些额外的保护，但对于不可逆转的破坏性或潜在的昂贵操作，对动作（例如通过电子邮件，SMS等）的外部确认是一个好主意。

但是安全而不是比对不起更好？

如果您仍然担心CSRF的AJAX端点可能以某种方式成为您不理解的方式的向量，请考虑能够从您的域执行请求并解析响应的远程脚本同样只是触发一个表单的请求，并从a上的一个值获取CSRF标记。同样，如果某人能够在您的网站上执行任意JavaScript并以他们所针对的当前用户的身份重新制作和读取请求，那么只需从您的DOM中读取CSRF令牌并从中提取即可一个已经在页面上的表单比AJAX糟糕。

摘要

使用HTTP只有饼干和CSRF令牌，以帮助防止CSRF和XSS攻击。

• 使用HTTP时只有提供方法通过AJAX获取CSRF令牌的cookie是不可利用的。

• 提供一种通过AJAX获取CSRF令牌的方法是一件好事，它可以在不影响安全性的情况下实现更好的用户体验。

• 考虑添加验证码和/或外部验证以确认适当的操作，以防止XSS。

你可以或者不能在一个给定的会话旋转用户CSRF令牌（一些中间件其实这样做是为了避免处理这个问题完全），但值得注意的是不为大多数CSRF令牌库典型行为。