形式欺骗和解决方法 [英] Form spoofing and methods to solve it

问题描述

我试图开发一个表单助手来防止表单欺骗。所以我想出了这个：

 < form ...> 
<？= form :: secure（）？> 
 ... 
< / form> 
  

这是用密钥'_token'戳记一个隐藏表单的一个令牌，它是ID的md5用户会话（1周后随机更新）。
然后在动作URL（从表单）：

$ $ p $ $ $ $ $ $ = $ is = ['_token']））？ $ _GET ['_ token']：null;
$ token =（is_null（$ token）和isset（$ _ POST ['_ token']））？ $ _POST ['_ token']：$ token;
if（form :: is_secure（$ token））{//检查给定的标记是否等于md5（用户标识）
... ok ...
} else {
...错误...
}

这是否可以防止表单欺骗或我错过了什么？如果用户标识在用户刚加载页面并提交表单的确切时刻到期，它只会打印一个错误，他应该再次提交表单，但那是可以接受的（很少见）。

我认为唯一可能出错的是如果潜在的攻击者能够获得用户会话ID，然后他可以将_token = id附加到它的请求并给它给用户浏览，但是在那个时候，如果攻击者拥有用户会话ID，它可以做任何他想做的事情。

我是对吗？如果没有，我该如何编辑我的代码来完成我的目标？ 您正在有效地重新发明轮子，因为令牌需要一个有效的会话进行验证，因此只会重复会话的安全层，而不会添加任何额外的内容。这相当于要求某人输入密码，然后再次要求确认。这可能会让每个人都感觉更好，但如果密码已被泄露，它只会减缓攻击，但不会阻止它。

这并不是说明你不应该认真对待这些事情或者解雇你的企图。我的理念是，表单的内容（通过 GET 或 POST ）传入的内容应与其他逻辑，如安全和计算，并且服务器不应将用户提供的数据视为除用户提供的数据以外的任何其他数据。理想情况下，任何人都可以发布任何表单操作，并且服务器/控制器将正确和一致地管理它。会话已验证（安全性），数据已过滤，然后进行验证，并且在用户实际使用Web表单时通过JS生成的任何值都会重新计算/验证。理想情况下，响应足够通用，可以是重定向或网络标准响应，以便请求者（无论是Web浏览器，命令行用户还是Web服务）都可以解释它。

如果上述情况如此，那么欺骗的重点和关注就会减少，而更侧重于分别增强安全层和验证层，最重要的是，做得很好的后端控制器很容易作为一个web服务后端被移植/重用。

长话短说：你的解决方案并不坏，它只是没有增加任何真正的安全性，只要我可以告诉，甚至可能暴露你的后端安全逻辑。如果你有特定的欺骗关注/威胁，最好是解决这个用例并且按照你的出路去做，而不是马上想出一个适合所有人的解决方案。可能会发现您的用例有不同的交换点需要解决的具体解决方案/考虑因素。

I'm trying to develop a form helper to prevent form spoofing. So i came up with this:

<form...>
<?=form::secure()?>
...
</form>

which stamps an hidden form with key '_token' with a token which is the md5 of the id of the user session (which is random and renewed after 1 week). And then at the "action" url (from the form):

$token = (isset($_GET['_token'])) ? $_GET['_token'] : null;
$token = (is_null($token) and isset($_POST['_token'])) ? $_POST['_token'] : $token;
if (form::is_secure($token)) { // checks if the given token is equal to md5(user id)
    ...ok...
} else {
    ...error...
}

Does that prevent form spoofing or I am missing something? In case the user id expires in the exact moment when the user has just loaded the page and then submit its form, it will just print an error and he should submit the form again, but thats acceptable (it's rare).

I thought that the only thing that could go wrong here is if the potential attacker is able to get the user session id and then he can attach ?_token=id to it's request and give it to the user to browse, but at that point, if the attacker has the user session id it can do whatever he wants anyway.

Am I right? If not, how can I edit my code to accomplish my goal?

解决方案

You are effectively reinventing the wheel, since the token requires a valid session to validate and thus only repeats the security layer of sessions while not adding anything extra. It is the equivalent of asking for someone to enter their password in and then asking for it again to be sure. It may make everyone feel better, but if the password has been compromised, it only slows down the attack but doesn't prevent it.

This isn't to suggest that you shouldn't take these things seriously or to dismiss your attempts. It is my philosophy that the content of the form (What is passed in via GET or POST) should be separated from other logic, such as security and calculations, and that the server should not consider user-supplied data as anything other than user-supplied data. Ideally anyone could post anything to a forms action, and the server/controller will manage it correctly and consistently. The session is verified (security), the data is sanitized and then validated, and any values that are generated via JS when the user is actually using the web form is recalculated/verified. The response, ideally, is generic enough, either a redirect or web-standard response, so that the requester, be it a web browser, command line user, or web service can interpret it.

If the above were the case, there would be less emphasis and concern of spoofing, more emphasis on enhancing security layers and validation layers separately, and, best of all, the back-end controller that did this well could easily be ported/reused as a web service backend.

Long story short: Your solution isn't bad, it just isn't adding any real security as far as I can tell, and may even expose your back-end security logic. If you have a specific spoofing concern/threat, it would be better to address that use case and work your way out rather than try to come up with a one-size-fits all solution right away. It may turn out that your use cases have specific solutions/considerations that need to addressed at different points of the exchange.

这篇关于形式欺骗和解决方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！