如何在GAE应用程序中最好地防止CSRF攻击？

那么，为GAE应用程序防止XSRF攻击的最佳方法是什么？想象一下以下内容：如何在GAE应用程序中最好地防止CSRF攻击？

任何人都可以看到该用户的公共对象，并且db.Model ID在请求中使用，以找出哪些对象显示。恶意用户现在拥有该ID。
恶意用户创建自己的对象并检出删除表单。他们现在知道如何删除具有特定ID的对象。
恶意用户获取无辜用户提交该用户对象的删除请求。

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

还有其他想法吗？ Jeff写了a post about this，并提出了几个方法 - 一个会在每个请求中改变的隐藏表单值，以及一个通过js写入表单的cookie值。我不想排除非javascript用户，所以cookie解决方案是不好的 - 对于隐藏的表单值，我将不得不在每个显示可删除对象的请求上执行数据存储写操作 - 这对于可伸缩性来说并不理想应用程序！

有没有其他想法呢？

来源

2008-10-13 Chris Marasti-Georg

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

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

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

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

来源

2009-05-25 23:16:50

简单：检查引荐者。如果它是空白的（某些代理和浏览器剥离查阅者）或从您自己的网站（或更具体地来自期望的源代码）允许它（有意）不可能设置。否则，拒绝并记录它。

编辑：Jeff用几种方法写了一个followup article来防止CSRF攻击。

来源

2008-10-13 20:20:33

那么，如果有人通过代理连接到我的网站，并遇到XSRF攻击，他们将不受保护？另外，杰夫提到引用者很容易被欺骗。我知道，作为一名用户，我可以轻松做到这一点，但是网站能否以某种方式让浏览器报告不同的推荐人？ – 2008-10-14 13:16:14

只有当代理或浏览器剥离引荐者时，他们才会受到保护。很少这样做，并且通过保护所有你能够保护的人，你使得攻击没有吸引力。是的，引用者是可伪造的，但攻击者无法通过任何代码说服用户在浏览器中执行代码。 – 2008-10-14 18:22:00

不允许空白Referer标题！如果从HTTPS页面请求HTTP页面，则不会发送[Referer]（http://stackoverflow.com/a/1361720/691281）。因此，如果您的表单位于HTTP页面上，攻击者可以使得引用者在CSRF攻击中变为空白。即使您的表单位于HTTPS页面上，我也会非常怀疑空白Referer标头。 – 2013-04-06 17:37:22

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

如果没有这样的散列或者它不同，请拒绝提交。

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

该方法应该在很多情况下保护你，但肯定仍然不是100％防弹。

搜索CSRF上的文章，也许你会发现这个Stack Overflow事情的一些很好的答案。 ;）

不要做任何引用者检查或客户端ip验证 - 它太容易出错（引用者信息可能被用户代理，代理或用户的首选项清除），客户端的IP可能会在表单创建和提交 - 不要惩罚用户进行动态IP地址分配。

来源

2008-10-15 14:38:52 macbirdie

如何在GAE应用程序中最好地防止CSRF攻击？

回答

相关问题