从 ajax 响应中获取新的 csrf 哈希令牌是否安全？
Is it secure to get new csrf hash token from ajax response?
我使用 zend 1 框架，我有多次使用 ajax 的表单，我用 csrf 保护它，但在第一次请求 csrf 令牌后将过期，我需要一个新的。从服务器端传递新的 csrf 令牌并在前端使用它进行新的 ajax 调用是否安全？
滚动 CSRF 令牌总是一个糟糕的设计，因为如果用户有多个 windows 打开，那么 CSRF 令牌当前有效的竞争条件就会发生。
在实施任何安全系统时，请尝试使用现有的库或有据可查的技术。不要妄自菲薄，阅读 CSRF prevention Cheat sheet.
旋转 CSRF 令牌不会提高安全性，因为相同的绕过技术将始终获得当前的 CSRF 令牌。所有 CSRF 缓解措施都依赖于 Same-Origin Policy - 如果您的应用程序具有 SOP 绕过 - 例如弱 crossdomain.xml 文件或不安全的 CORS 规则集或 XSS - 那么攻击者可以利用此漏洞读取 任何 HTTP 响应。对于任何给定的 Web 应用程序，某些 HTTP 响应必须具有 CSRF 令牌，并且可以使用 SOP 旁路来读取此令牌并在浏览器和 Web 应用程序之间建立交互。
采用何种类型的 CSRF 缓解并不重要 - XSS 始终可用于强制浏览器执行用户可以执行的任何操作。如果存在反射型 XSS 漏洞的请求还需要 CSRF 令牌，那么将很难或不可能被利用。为此，CSRF & XSS 有一种剪刀石头布的关系。
如果您遇到防伪令牌行为方面的问题，您是否考虑过使用 SameSite cookie 标志？
长话短说。当您发送跨源请求（例如，站点 A 向站点 B 发送请求）时，您的浏览器会非常友好地检查您是否有该站点的 cookie，因此，您可能容易受到 XSRF 攻击.我们使用防伪令牌在发送请求的有效实体与服务器之间创建共享秘密。但如您所见，实施过程中可能存在一些问题。
另一方面，同站点 cookie 标志允许您配置如何通过跨源请求发送 cookie。有严格模式和松散模式两种模式
在严格模式下，您的 cookie 永远不会通过跨源请求发送。这看起来是个不错的方法，但您还需要考虑到 cookie 不会通过 GET 请求发送，因此如果有人被重定向到您的站点，他将需要重新登录，因为 cookie 不是在那个时候发送的请求。
松散模式的作用几乎相同，但它允许您的 cookie 通过安全的 HTTP 动词（GET、HEAD、OPTIONS 和 TRACE）发送，因此您可以防御 POST/PUT CSRF 攻击，但您仍然会在用户通过 GET 请求浏览时获得良好的行为。
编辑： 只是补充一点，即使 SameSite cookie 标志听起来是一个非常好的选项，它也只被 Chrome 和 Opera 实现，所以如果你用户群是使用各种不同浏览器和不同版本的人，它可能不是您应用的最佳选择。
我使用 zend 1 框架，我有多次使用 ajax 的表单，我用 csrf 保护它，但在第一次请求 csrf 令牌后将过期，我需要一个新的。从服务器端传递新的 csrf 令牌并在前端使用它进行新的 ajax 调用是否安全？
滚动 CSRF 令牌总是一个糟糕的设计，因为如果用户有多个 windows 打开，那么 CSRF 令牌当前有效的竞争条件就会发生。
在实施任何安全系统时，请尝试使用现有的库或有据可查的技术。不要妄自菲薄，阅读 CSRF prevention Cheat sheet.
旋转 CSRF 令牌不会提高安全性，因为相同的绕过技术将始终获得当前的 CSRF 令牌。所有 CSRF 缓解措施都依赖于 Same-Origin Policy - 如果您的应用程序具有 SOP 绕过 - 例如弱 crossdomain.xml 文件或不安全的 CORS 规则集或 XSS - 那么攻击者可以利用此漏洞读取 任何 HTTP 响应。对于任何给定的 Web 应用程序，某些 HTTP 响应必须具有 CSRF 令牌，并且可以使用 SOP 旁路来读取此令牌并在浏览器和 Web 应用程序之间建立交互。
采用何种类型的 CSRF 缓解并不重要 - XSS 始终可用于强制浏览器执行用户可以执行的任何操作。如果存在反射型 XSS 漏洞的请求还需要 CSRF 令牌，那么将很难或不可能被利用。为此，CSRF & XSS 有一种剪刀石头布的关系。
如果您遇到防伪令牌行为方面的问题，您是否考虑过使用 SameSite cookie 标志？
长话短说。当您发送跨源请求（例如，站点 A 向站点 B 发送请求）时，您的浏览器会非常友好地检查您是否有该站点的 cookie，因此，您可能容易受到 XSRF 攻击.我们使用防伪令牌在发送请求的有效实体与服务器之间创建共享秘密。但如您所见，实施过程中可能存在一些问题。
另一方面，同站点 cookie 标志允许您配置如何通过跨源请求发送 cookie。有严格模式和松散模式两种模式
在严格模式下，您的 cookie 永远不会通过跨源请求发送。这看起来是个不错的方法，但您还需要考虑到 cookie 不会通过 GET 请求发送，因此如果有人被重定向到您的站点，他将需要重新登录，因为 cookie 不是在那个时候发送的请求。
松散模式的作用几乎相同，但它允许您的 cookie 通过安全的 HTTP 动词（GET、HEAD、OPTIONS 和 TRACE）发送，因此您可以防御 POST/PUT CSRF 攻击，但您仍然会在用户通过 GET 请求浏览时获得良好的行为。
编辑： 只是补充一点，即使 SameSite cookie 标志听起来是一个非常好的选项，它也只被 Chrome 和 Opera 实现，所以如果你用户群是使用各种不同浏览器和不同版本的人，它可能不是您应用的最佳选择。