从ajax响应中获取新的csrf哈希令牌是否安全？

Question

我使用zend 1框架，我有多次使用ajax的表单，我用csrf保证它，但在第一次请求csrf标记将过期后，我需要新的一个。从服务器端传递新的csrf标记并将其用于新的ajax调用的前端是否安全？

Answer 1

滚动的CSRF令牌总是一个糟糕的设计，因为如果用户打开了多个窗口，就会出现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有一种岩石剪刀关系。

Answer 2

如果您遇到防伪标记行为方面的问题，您是否考虑过使用SameSite Cookie标志？

长话短说。当您发送一个跨域请求时（例如，站点A向站点B发送请求），您的浏览器将足够友好以检查您是否拥有该站点的Cookie，因此，您可能容易受到XSRF攻击。我们使用防伪令牌在发送请求的有效实体和服务器之间创建共享密钥。但正如你所看到的，执行过程中可能会有一些问题。

另一方面，同一站点Cookie标志允许您配置Cookie如何通过跨源请求发送。有两种模式，严格模式和宽松模式。

在严格模式下，您的cookies永远不会通过跨源请求发送。这似乎是一个很好的方法，但你也需要考虑到cookie不会通过GET请求发送，所以如果有人被重定向到你的站点，他将需要再次登录，因为cookie没有被发送请求。

宽松模式几乎相同，但它允许您的cookie通过安全的HTTP动词（GET，HEAD，OPTIONS和TRACE）发送，因此您可以防止POST/PUT CSRF攻击，但是您用户通过GET请求浏览仍然会有很好的行为。

编辑：只要添加即使SameSite cookie标志听起来像是一个非常好的选项，它只能由Chrome和Opera实现，所以如果您的用户群是使用各种不同浏览器和不同浏览器的人版本，它可能不是您的应用程序的最佳选择。