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

Question

只是突然想到了哈。
比如这个用户，本来是修改的是id=10的文章，然后他出去了，旁边来个人给他用firebug这样的东东，把hiddren修改成11了（此用户有权访问10和11）。那么此用户回来提交的时候，其本意是修改10，结果很可能会把11的给修改掉（如果没有防止此种修改方式的对应方法）。这个比喻虽然无聊了点，但确实是可以这样做的。再延伸一点，比如ajax提交给ashx的数据，如果也有这样的hiddren关键词的地方，应该也存在同样的问题。
所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。

Answer 1

只是突然想到了哈。
比如这个用户，本来是修改的是id=10的文章，然后他出去了，旁边来个人给他用firebug这样的东东，把hiddren修改成11了（此用户有权访问10和11）。那么此用户回来提交的时候，其本意是修改10，结果很可能会把11的给修改掉（如果没有防止此种修改方式的对应方法）。这个比喻虽然无聊了点，但确实是可以这样做的。再延伸一点，比如ajax提交给ashx的数据，如果也有这样的hiddren关键词的地方，应该也存在同样的问题。
所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。
他自己出门不关闭IE,旁边有人把他网站内容都删除了也行,这跟firebug有任何关系?

Answer 2

就算不用firebug,我也可以自己写段代码模拟登陆,模拟提交,然后我代码里写错了,结果把东西更新没了,这能怪谁?自己作死

Answer 3

只是突然想到了哈。
比如这个用户，本来是修改的是id=10的文章，然后他出去了，旁边来个人给他用firebug这样的东东，把hiddren修改成11了（此用户有权访问10和11）。那么此用户回来提交的时候，其本意是修改10，结果很可能会把11的给修改掉（如果没有防止此种修改方式的对应方法）。这个比喻虽然无聊了点，但确实是可以这样做的。再延伸一点，比如ajax提交给ashx的数据，如果也有这样的hiddren关键词的地方，应该也存在同样的问题。
所以就想请教一下如何避免或者拒绝这样的恶(无)意(聊）的篡改关键数据方法。
他自己出门不关闭IE,旁边有人把他网站内容都删除了也行,这跟firebug有任何关系?
淡定淡定，最终的目的就是有没方法保证接收到的数据和发送出去的数据是同一条记录，尤其这样前台用hiddren来保存关键数据的形式下。

Answer 4

显然，想要验证，必须要把状态保存在一个地方，并且客户端无法修改。方法你都说多了，可以是服务端session，或者是传递给客户端加密后的值，客户端提交时携带。最好是传递给客户端，因为为了防止CSRF攻击，常用方式就是需要一个这样的hidden字段，里面是加密后的一些内容，你可以自行实现，或者基于自带的IAntiForgeryAdditionalDataProvider，把当前的id也拼进去加密。