11

那么，对于 GAE 应用程序来说，防止 XSRF 攻击的最佳方法是什么？想象一下：

  1. 任何人都可以看到用户的公共对象，并且在请求中使用 db.Model id 来确定要显示的对象。恶意用户现在拥有该 ID。
  2. 恶意用户创建自己的对象并签出删除表单。他们现在知道如何删除具有特定 id 的对象。
  3. 恶意用户让无辜用户提交对该用户对象的删除请求。

我可以添加哪些步骤来防止#3？请注意，当我说 ID 时，我使用的是密钥的实际 ID 部分。我的一个想法是在删除请求中使用完整的键值，但这会阻止恶意用户解决这个问题吗？据我所知，密钥是模型类类型、应用程序 ID 和对象实例 ID 的某种组合，因此如果他们愿意，他们可能会从 id 派生密钥。

还有其他想法吗？Jeff 写了一篇关于这个的帖子，并提出了一些方法——一个隐藏的表单值，它会在每次请求时改变，以及一个通过 js 写入表单的 cookie 值。我不想排除非 javascript 用户，因此 cookie 解决方案不好 - 对于隐藏的表单值，我必须对显示可删除对象的每个请求进行数据存储写入 - 对于可扩展的对象来说，这不是理想的情况应用程序！

还有其他想法吗？

4

3 回答 3

13

当您生成允许用户删除对象的页面时，生成一个随机标记并将其包含在隐藏的表单字段中。还使用该值设置一个仅限 HTTP 的 cookie。当您收到删除请求时，请检查表单中的随机令牌和 cookie 中的值是否匹配。

您的随机令牌不应该只是一个随机数。您应该加密随机数和用户身份的组合，以使攻击者难以伪造自己的令牌。您还应该对存储在表单中的值和存储在 cookie 中的值使用不同的加密密钥，因此如果其中一个令牌确实泄漏，攻击者仍然难以伪造另一个令牌。

此方法通过表单中是否存在安全令牌来验证删除请求是否来自您的表单；并且不需要写入数据存储。

这种方法仍然容易受到跨站点脚本攻击，攻击者可以从表单中检索隐藏值或提交表单，因此请彻底测试您的站点是否存在跨站点脚本漏洞。这种方法也容易受到“点击劫持”攻击。

于 2009-05-25T23:16:50.670 回答
5

很简单：检查推荐人。（故意）不可能使用 Javascript、HTML 表单等设置它。如果它是空白的（某些代理和浏览器剥离引用者）或来自您自己的站点 - 或者更具体地说来自预期的来源 - 允许它。否则，拒绝它并记录它。

编辑：Jeff 写了一篇后续文章，介绍了几种防止 CSRF 攻击的方法。

于 2008-10-13T20:20:33.667 回答
4

在显示表单的服务器响应中，创建一个魔术哈希（基于客户端 ip + 日期/时间 + 随机盐等）。将其放入 cookie 并存储在服务器上的某个位置。在提交操作处理期间，根据数据库条目检查 cookie 哈希。

如果没有这样的哈希值或它不同，则拒绝提交。

成功提交后，您可以删除哈希条目，将其状态更改为已提交 - 任何适合您的。

在许多情况下，这种方法应该可以保护您，但肯定仍然不是 100% 防弹的。

搜索有关 CSRF 的文章，也许您会在Stack Overflow上找到一些好的答案。;)

不要进行任何引荐来源网址检查或客户端 IP 验证 - 这太容易出错（引荐来源网址信息可能会被用户代理、代理或用户的偏好清除）并且客户端的 IP 可能会在表单创建和提交之间发生变化 - 不要t 惩罚用户的动态 IP 地址分配。

于 2008-10-15T14:38:52.607 回答