类似火狐FireBug如何解决在客户端恶意修改数据提交

比如某个用户可以操作后台的某个权限（比如更新一个栏目下的文章），如果前台有个hidden来标记此次读取的是哪篇文章的ID，后台读取这个hidden来更新文章。这样的情况下，用户用FireBug修改了这个值（比如读取的是id为10的文章），用户在修改完文章内容后，用firebug修改了这个hidden为11然后提交，那么后台更新的文章id就是11。这是不正确的（即使用户有权限更新10和11）。这种情况有办法避免吗？除了用session来保存id、或者加密这个id，后台接收后跟加密的值对比以外。
5分	真正的逻辑应该都在服务端,比如用户只有修改10的权限,却要修改成11提交,后台就不应该把它真正执行而有权限修改10和11的人没必要这样搞没有权限的人搞了也白搞
	引用 1 楼: 真正的逻辑应该都在服务端… 只是突然想到了哈。比如这个用户，本来是修改的是id=10的文章，然后他出去了，旁边来个人给他用firebug这样的东东，把hiddren修改成11了（此用户有权访问10和11）。那么此用户回来提交的时候，其本意是修改10，结果很可能会把11的给修改掉（如果没有防止此种修改方式的对应方法）。这个比喻虽然无聊了点，但确实是可以这样做的。再延伸一点，比如ajax提交给ashx的数据，如果也有这样的hiddren关键词的地方，应该也存在同样的问题。所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。
	引用 3 楼 5653325 的回复: 只是突然想到了哈。.. 所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。他自己出门不关闭IE,旁边有人把他网站内容都删除了也行,这跟firebug有任何关系?
	就算不用firebug,我也可以自己写段代码模拟登陆,模拟提交,然后我代码里写错了,结果把东西更新没了,这能怪谁?自己作死
	引用 4 楼 Z65443344 的回复: Quote: 引用 3 楼 5653325 的回复: fieldset> Quote: 引用 1 楼 Z65443344 的回复: 不明白纠结这个有什么意义真正的逻辑应该都在服务端,比如用户只有修改10的权限,却要修改成11提交,后台就不应该把它真正执行而有权限修改10和11的人没必要这样搞没有权限的人搞了也白搞只是突然想到了哈。比如这个用户，本来是修改的是id=10的文章，然后他出去了，旁边来个人给他用firebug这样的东东，把hiddren修改成11了（此用户有权访问10和11）。那么此用户回来提交的时候，其本意是修改10，结果很可能会把11的给修改掉（如果没有防止此种修改方式的对应方法）。这个比喻虽然无聊了点，但确实是可以这样做的。再延伸一点，比如ajax提交给ashx的数据，如果也有这样的hiddren关键词的地方，应该也存在同样的问题。所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。他自己出门不关闭IE,旁边有人把他网站内容都删除了也行,这跟firebug有任何关系? 淡定淡定，最终的目的就是有没方法保证接收到的数据和发送出去的数据是同一条记录，尤其这样前台用hiddren来保存关键数据的形式下。
33分	显然，想要验证，必须要把状态保存在一个地方，并且客户端无法修改。方法你都说多了，可以是服务端session，或者是传递给客户端加密后的值，客户端提交时携带。最好是传递给客户端，因为为了防止CSRF攻击，常用方式就是需要一个这样的hidden字段，里面是加密后的一些内容，你可以自行实现，或者基于自带的IAntiForgeryAdditionalDataProvider，把当前的id也拼进去加密。

比如某个用户可以操作后台的某个权限（比如更新一个栏目下的文章），如果前台有个hidden来标记此次读取的是哪篇文章的ID，后台读取这个hidden来更新文章。这样的情况下，用户用FireBug修改了这个值（比如读取的是id为10的文章），用户在修改完文章内容后，用firebug修改了这个hidden为11然后提交，那么后台更新的文章id就是11。这是不正确的（即使用户有权限更新10和11）。这种情况有办法避免吗？除了用session来保存id、或者加密这个id，后台接收后跟加密的值对比以外。
5分	真正的逻辑应该都在服务端,比如用户只有修改10的权限,却要修改成11提交,后台就不应该把它真正执行而有权限修改10和11的人没必要这样搞没有权限的人搞了也白搞
	引用 1 楼: 真正的逻辑应该都在服务端… 只是突然想到了哈。比如这个用户，本来是修改的是id=10的文章，然后他出去了，旁边来个人给他用firebug这样的东东，把hiddren修改成11了（此用户有权访问10和11）。那么此用户回来提交的时候，其本意是修改10，结果很可能会把11的给修改掉（如果没有防止此种修改方式的对应方法）。这个比喻虽然无聊了点，但确实是可以这样做的。再延伸一点，比如ajax提交给ashx的数据，如果也有这样的hiddren关键词的地方，应该也存在同样的问题。所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。
	引用 3 楼 5653325 的回复: 只是突然想到了哈。.. 所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。他自己出门不关闭IE,旁边有人把他网站内容都删除了也行,这跟firebug有任何关系?
	就算不用firebug,我也可以自己写段代码模拟登陆,模拟提交,然后我代码里写错了,结果把东西更新没了,这能怪谁?自己作死
	引用 4 楼 Z65443344 的回复: Quote: 引用 3 楼 5653325 的回复: fieldset> Quote: 引用 1 楼 Z65443344 的回复: 不明白纠结这个有什么意义真正的逻辑应该都在服务端,比如用户只有修改10的权限,却要修改成11提交,后台就不应该把它真正执行而有权限修改10和11的人没必要这样搞没有权限的人搞了也白搞只是突然想到了哈。比如这个用户，本来是修改的是id=10的文章，然后他出去了，旁边来个人给他用firebug这样的东东，把hiddren修改成11了（此用户有权访问10和11）。那么此用户回来提交的时候，其本意是修改10，结果很可能会把11的给修改掉（如果没有防止此种修改方式的对应方法）。这个比喻虽然无聊了点，但确实是可以这样做的。再延伸一点，比如ajax提交给ashx的数据，如果也有这样的hiddren关键词的地方，应该也存在同样的问题。所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。他自己出门不关闭IE,旁边有人把他网站内容都删除了也行,这跟firebug有任何关系? 淡定淡定，最终的目的就是有没方法保证接收到的数据和发送出去的数据是同一条记录，尤其这样前台用hiddren来保存关键数据的形式下。
33分	显然，想要验证，必须要把状态保存在一个地方，并且客户端无法修改。方法你都说多了，可以是服务端session，或者是传递给客户端加密后的值，客户端提交时携带。最好是传递给客户端，因为为了防止CSRF攻击，常用方式就是需要一个这样的hidden字段，里面是加密后的一些内容，你可以自行实现，或者基于自带的IAntiForgeryAdditionalDataProvider，把当前的id也拼进去加密。

文章评论已关闭！