那么,防止GAE应用程序的XSRF攻击的最佳方法是什么？想象一下:
任何人都可以看到用户的公共对象,并且在请求中使用db.Model id来确定要显示的对象.恶意用户现在拥有该ID.
恶意用户创建自己的对象并检出删除表单.他们现在知道如何删除具有特定id的对象.
恶意用户让无辜的用户为该用户的对象提交删除请求.
我可以添加哪些步骤来防止#3？请注意,当我说ID时,我正在使用密钥的实际ID部分.我的一个想法是在删除请求中使用完整的键值,但这会阻止恶意用户能够解决这个问题吗？据我所知,关键是模型类类型,应用程序ID和对象实例ID的某种组合,因此如果他们愿意,他们可能从id派生密钥.
还有其他想法吗？Jeff撰写了一篇关于此的文章,并提出了几个方法 - 一个隐藏的表单值,每个请求都会改变,以及通过js写入表单的cookie值.我不想排除非JavaScript用户,因此cookie解决方案不好 - 对于隐藏的表单值,我必须在显示可删除对象的每个请求上执行数据存储区写入 - 这不是可扩展的理想情况应用程序!
还有其他想法吗？
当您生成允许用户删除对象的页面时,生成随机令牌并将其包含在隐藏的表单字段中.还要使用该值设置仅HTTP的cookie.收到删除请求时,请检查表单中的随机令牌和Cookie中的值是否匹配.
您的随机令牌不应只是一个随机数.您应该加密随机数和用户身份的组合,以使攻击者难以伪造自己的令牌.您还应该为表单中存储的值和存储在cookie中的值使用不同的加密密钥,因此如果其中一个令牌泄漏,攻击者仍然难以伪造另一个令牌.
此方法通过表单中安全令牌的存在来验证删除请求是否来自您的表单; 并且不需要写入数据存储区.
此方法仍然容易受到跨站点脚本攻击,攻击者可以从表单中检索隐藏值或提交表单,因此请彻底测试您的站点是否存在跨站点脚本漏洞.这种方法也容易受到"点击劫持"攻击.
简单:检查引用者.(故意)不可能使用Javascript,HTML表单等设置它.如果它是空白的(某些代理和浏览器剥离引用者)或来自您自己的站点 - 或者更具体地来自预期的源 - 允许它.否则,拒绝并记录它.
编辑:杰夫撰写了一篇后续文章,其中有几种方法可以防止CSRF攻击.
京公网安备 11010802040832号 | 京ICP备19059560号-6 