如何在GAE应用程序中最好地防止CSRF攻击？ [英] How to best prevent CSRF attacks in a GAE app?

问题描述

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

1. 任何人都可以看到用户的公共对象，并且在请求中使用db.Model id来计算出哪个对象以显示。恶意用户现在拥有该ID。


2. 恶意用户创建自己的对象并检出删除表单。他们现在知道如何删除具有特定ID的对象。


3. 恶意用户将无辜用户提交该用户对象的删除请求。

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

还有其他想法吗？ Jeff写了关于这个的帖子，并提出了一些方法 - 一种隐藏的表单值这将在每个请求上发生变化，并通过js写入表单中的cookie值。我不想排除非javascript用户，所以cookie解决方案并不好 - 对于隐藏的表单值，我必须在每个显示可删除对象的请求上执行数据存储写操作 - 这对于可伸缩性来说并不理想

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

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

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

这种方法仍然容易受到跨站点脚本攻击的攻击，攻击者可以从表单中检索隐藏值或提交该表单，如此彻底地测试您的网站的跨站点脚本漏洞。这种方法也容易受到点击劫持攻击。

So, what is the best way to prevent an XSRF attack for a GAE application? Imagine the following:

1. Anyone can see a user's public object, and the db.Model id is used in the request to figure out which object to show. Malicious user now has the id.
2. Malicious user creates their own object and checks out the delete form. They now know how to delete an object with a certain id.
3. Malicious user gets innocent user to submit a delete request for that user's object.

What steps can I add to prevent #3? Note that when I say ID, I am using the actual ID part of the key. One idea I had was to use the full key value in delete requests, but would that prevent a malicious user from being able to figure this out? As far as I know, the key is some combination of the model class type, the app id, and the object instance id, so they could probably derive the key from the id if they wanted to.

Any other ideas? Jeff wrote a post about this, and suggested a couple methods - a hidden form value that would change on each request, and a cookie value written via js to the form. I won't want to exclude non-javascript users, so the cookie solution is no good - for the hidden form value, I would have to do a datastore write on every request that displayed a deletable object - not an ideal situation for a scalable app!

Any other ideas out there?

解决方案

When you generate the page that lets the user delete an object, generate a random token and include it in a hidden form field. Also set a HTTP-only cookie with that value. When you receive a delete request, check that the random token from the form and the value from the cookie match.

Your random token shouldn't just be a random number. You should encrypt the combination of a random number and the user's identity, to make it difficult for attackers to forge their own tokens. You should also use different encryption keys for the value stored in the form and the value stored in the cookie, so if one of the tokens does leak, it is still difficult for an attacker to forge the other token.

This approach verifies that the delete request originates from your form, by the presence of the security token in the form; and doesn't require writing to the datastore.

This approach is still vulnerable to cross-site scripting attacks, where an attacker could retrieve the hidden value from the form or submit the form, so thoroughly test your site for cross-site scripting vulnerabilities. This approach is also vulnerable to "clickjacking" attacks.

这篇关于如何在GAE应用程序中最好地防止CSRF攻击？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！