具有 CSRF 保护的 Service Worker 后台同步的最佳实践模式答案

【问题标题】：Best practice pattern for service worker background-sync with CSRF protection具有 CSRF 保护的 Service Worker 后台同步的最佳实践模式
【发布时间】：2016-08-05 18:29:46
【问题描述】：

我有一个使用嵌入在页面中的一次性令牌来确保 CSRF 保护的请求 - 攻击者可能能够欺骗我的用户发出非法请求，但他们无法获得令牌，即使他们是否可以随每个请求而更改并且可以过期。

到目前为止，很安全。

我想通过服务工作者实现后台同步，以便用户可以离线发布数据，然后在他们获得连接时发送该数据。

但是，这意味着页面无法获取 CSRF 令牌，并且在用户构建它时与请求链接的任何令牌在实际发送数据时都可能无效。

这似乎是任何进步网站的普遍问题，处理它的最佳做法是什么？

我认为后台同步可以请求一个新令牌，将其应用于要发送的数据然后发送它，这仍然是一个 CSRF 攻击者无法利用的循环，但我不是肯定的。任何人都可以确认这一点吗？

是否有一些我缺少的 Service Worker 或后台同步功能？

【问题讨论】：

标签： service-worker csrf-protection background-sync

【解决方案1】：

我没有资格谈论 CSRF 主题的“最佳实践”，但根据我对 OWASP guidelines on CSRF 的理解，您的想法是正确的。

目前，我以类似的方式使用 OAuth：向各个客户端发出刷新和不记名令牌。刷新令牌的生命周期明显长于不记名令牌。客户端可以选择使用刷新令牌来铸造新的不记名令牌。一些客户可能会选择“完全轮换”，即每次请求都有一个新的承载。有些人可能会选择使用承载，直到它报告失败，然后再铸造一个新的。

在您的场景中，您的后台同步将请求和接收刷新和不记名令牌。它可以继续使用手头的不记名令牌构建 URL，然后在尝试失败时同步时，使用刷新令牌生成新的不记名并使用新不记名重建 URL。当然，如果刷新已过期（或已被撤销），则说明您离线时间过长，需要重新验证。

【讨论】：

为响应干杯 - 我想出了类似的东西，但我确信有安全专家可以在我的意见中找出漏洞。
可能，虽然我注意到答案不是我错过的服务工作者的实施特定的东西，在这种情况下，我更有可能在这里得到答案。
面临类似的问题。我认为为离线保存的页面应该具有安全性。但是，如果您将 service worker 设计为 api，则可能不需要它。软件毕竟在客户端 com 上。身份验证应该通过 api 和 json 响应在后台发生在服务器端。只是一个想法。