如果防止手动篡改请求参数

post不可行，可以模拟，比如在firebug里修改，或者用户可以自己写个表单或用JS发post请求
简单的说就是有人故意在破坏

你的用户权限拦截器是干嘛的你可以将你的action 都映射了不显示真实action路径

权限拦截器能知道
xxx.com?涨工资=100
是合法的？
xxx.com?涨工资=1000
是非法的？
如何知道?

业务逻辑设计有问题。如果是操作发生的，人家填100也好，填1000也行，和手工修改效果一样。防范修改这个参数根本没必要，直接允许修改，修改就认为是正常修改提交的,关键是这个人的操作权限，允不允许提交这种修改，如果允许进行工资修改的话，他无论是正常填写的还是修改URL导致的，都一律由他本人负责就是了。如果考虑若有什么间谍软件会自动修改的话，那就麻烦了，而且一般人恐怕也做不到这一点。考虑多了。

可以.获取前地址就行了.如果前地址不是你网站的或为null的话,那么就是手动的.

同意4楼的做法，用一个<input type="hidden" name="model.gongzi"/>把值映射到后台去。

跟权限没有关系，我很想迷信火龙这么高分的人，但是我肯定他没有理解我的意思。我再强调一次跟权限没有关系，举个例子来说HR登录后，显然是已经拥有了调整工资的权限，就算他手动修改了URL从权限的角度来说，这肯定是合法的请求，因为他拥有HR权限，但是我依然不允许让他手动的修改URL，我现在要解决的问题是当我得到一个请求的时候，我想知道这个请求是不是被篡改过，仅此而已，跟权限没有关系，调整工资只是一个例子，我要解决的是技术问题：判断一个URL是否是被篡改过的！！
而不是要讨论权限问题，其实类似的实现淘宝和很多银行系统已经有了，我只是没有完全懂，没能自己搞一个完成的思路出来，我乐意接受批评，但请各位高手稍微静一下，再批评嘛，来了就给说结构有问题，我要讨论的是如何让我们的URL 具备一种特性，能让我们判断这是否是一个被篡改过的URL！我认为这是一个非常有用的东西，如果我们解决了这个问题。
类似的思路可能是：
本来的url
xxx.com?涨工资=100
加密成 xxx.com?涨工资=100&key={"涨工资=100"MD5}
发到服务器后，对参数加密后，如果能与KEY匹配，就说明没有被篡改过，否则肯定是被篡改过。
大概思路就很类似，当然这只是思路，肯定不能用，比如别人知道我们是MD5加密的，别人依然可以篡改后，加个KEY我想看看CSDN里有没有高手有类似的经验

试问如果一个人可以修改工资填了100和直接敲地址变1000又怎样?不都一样么?如果这个人没权限那么在提交的servlet中把这个请求过滤掉就好了,如果说要在一个范围内做限制不一样么?如果真要这样你判断一下上一个请求地址?

请看20楼，我只是举个例子，我的核心问题不是害怕工资填错了，是判断一个URL是否是被篡改过的？

你用AJAX，用户也可以伪造啊

ajax参数你怎么伪造求解释

firebug啊，就能看到你这个请求的所有信息，然后自己写歌js方法，发一个和你一摸一样的ajax请求啊

这个真没想到有什么方式可以避免，再说了，一样可以通过程序来模拟get和post提交，想提交多少就是多少。
我觉得可以把参数编码，自定义编码规则，之后接收到数据后服务器端解码吧

加密应该是一个可行的方法吧，因为http请求都是可以模拟的，不管怎么传数据，或者加hidden都可以模拟出来的。只能通过加密了，最后在把js加密，或者生成机器代码。但是这个也不是绝对安全的。
还有什么方法，请高手们指点。

围观，能不能用 ActiveX 或 Applet 加密，这个黑箱不给用户看到 JavaScript 是如何加密的，只给出结果来提交的。

不知道啊，不过我个人认为，恐怕不到万不得已，这两个不该用吧，兼容性被打击掉了，不过用flex插件是不是可以代替你的ActiveX或applet，貌似解决了黑箱加密，如果不被反编译的话，还有没有更好的方案呢？

你应该要补点网络基本常识。
你的需求不可能被实现！
URL是明码发送的，所以必然有办法改。数据可以用SSL方式加密传输，修改URL是没办法防的。

大家都是黑客啊，都厉害，说的太对了。你输入100，url改成1000，跟权限有什么关系；还有你隐藏值和ajax传值，人家查看源代码，模仿url传值，依旧可以成功。还有那个加密，你的加密跟修改价钱有什么关系。

只要你用URL传值，讨论这个问题就没什么意义。你对WEB开发的基础认识都存在缺环。业务问题，不是你想讨论不讨论的问题，而是你本身存在错误，要不要纠正的问题。这个问题，你直接把GET提交改成POST提交就是了，虽然对于懂的人来说一样可以修改，至少可以应付一般的普通用户了（包括你在内不也没有认清这些常识吗）。不用URL传，就没有要不要管修改URL的问题了。至于有没有其它方法来辨别确实是手动改变了正常的URL提交，其实方法不少，但这个问题本身根本没什么意义，所以对它说什么方法也没用。真正的解决问题，不是顺着楼主错误的想法去解决错误的需求，而是告诉你什么才是对的。

get改成post？大牛逗小朋友呢？这不是大学生的毕业设计，我们的安全等级要求接近于银行。
显然，这位大牛没有研究过这个领域，这种技术在淘宝以及很多金融银行系统被广泛使用，我不是第一个需要的。“至于有没有其它方法来辨别确实是手动改变了正常的URL提交，其实方法不少”这话听起来很玄，虽然大哥已经三个勋章，但口说无凭，希望你亮出真家伙，给大家学习学习。

冷静点嘛哥们，
SSL根本解决不了这个问题，用户只需要在firebug里，就能看到你发出去的请求什么样的，就可以模拟了，何必去网络上截获呢？
看来你回帖前思考的时间太短，建议阅读20楼和37楼。高手太多，批评者太多，仔细思考的人太少

你还是谦虚点吧，银行系统？你少扯淡了。国外网银大多使用https技术，传送加密数据。
但是这种方法无法防止客户在浏览器端的黑客程序，比如浏览器装了黑客插件等。
另外在SSL建立前的过程，即客户端和服务器协商加密协议阶段，也有是可能被拦截绑架的。国内网银大多只支持IE, 因为用了ActiveX技术。
感觉比上一种略微安全，前提是加密算法不被知晓，客户端未被反编译篡改。按照现有的网络协议，世界上没有防改URL的方法。

这个不是权限的问题，在项目中我们不可避免的要将一些参数传递出去，这样的话就会吧参数名称的参数值显示在url中，如果谁直接修改url岂不是会造成不是错误的错误，如果涉及到一下安全的项目，这问题就大了，所以这次我们讨论的问题是“如何防止用户直接修改url地址”，我在项目中也是经常遇到此问题，很是郁闷，现在求解答……

别人不把你当专家，就不行啊？你才知道我们讨论的是客户端的问题啊？既然是客户端，就是在提前之前的工作，与网络有什么关系，要啥网络常识？
装什么专家嘛，你说世界上没有这个技术，那你说的ActiveX是什么？
跟网络，跟SSL有啥关系，扯HTTPS，有一分钱的关系吗？拿英文单词吓唬人呢？装专家？
按照网络协议？跟网络有啥关系？你不是已经理解了我们讨论的事提交之前的问题，净拿名词出来忽悠小朋友。

你说对了，我们讨论的的确是提交之前的事情，所以跟网络没有关系，既然跟网络没有关系，就谈不上HTTPS，更谈不上所谓的网络协议，我们谈的是，提交之前生成一个怎么样的url，以帮助服务器来判断是否被篡改过。
你说你认为世界上没有方法，我支持你，这是你的观点没有问题。但是你要我补充网络知识，跟主题不符啊，HTTPS...网络协议....更是跟主题没有关系啊大家都是来学习的，您老人家火气小点儿嘛，就算你有火气，也该指正道啊，别人问你去天安们怎么走，你说今天的天气不利于飞机起飞

引用：只要你用URL传值，讨论这个问题就没什么意义。

支付宝支付请求的加密方式如下
url?param1=a&param2=b&sign=MD5(param1+param2)
我们是否可以参考类似方式呢？
当然，这个加密规则肯定需要自定义并且很复杂才可以，服务器端将接受到的参数以同样的规则加密后和sign比较，以判断参数是否被修改过

其实，想lz之前说的，用个flex开发一个提交页面，应该就可以了

是的，flex几乎解决了这个问题我们现在就是这样做的
原请求
xxx.com?涨工资=100000
变成
xxx.com?涨工资=100000&key=【flex里MD5(xxx.com?涨工资=100000)】
到了后台如果你改了前边的参数，肯定就和后边的KEY不匹配，这似乎已经解决了这个问题。这只是我想出来的思路，因为
第一，我不是大牛，第二，flex可以被反编译，被别人很轻松的知道我的key的生成规则CSDN这么多大牛，我认为我这个很简单的问题，一定有无数前辈解决过，所有跑来问问有没有更好的解决方案

事实上flex被翻编译是非常容易，目前这种方式依然不满意

用户直接在表单里填想要的数据，flex就为他生成了key了，有什么理由要去修改URL参数呢？

楼主不要这种问题上纠结了，既然HR有权限给别人涨工资，那么涨多少就不是你的事情。
你要做的就是让非HR不能恶意的涨工资就行了。

我想到了一个笨办法，就是在用户先get页面的时候我记录下这个页面的id的序列号，在post 或者put 以及 del方法的时候我都将这页的id一起传递给服务端，再检查提交过来的id序列是否和之前记录的一周就可以判断用户是否篡改过表单，我主要是判断表单是否篡改，url好像比较难，没法参照而且你那个100是客服端生成，控制不了

正好也在研究这个问题，来挖一下坟。
这里面其实有两个问题，楼主一直没分开来说清楚（也可能是楼主遇到的需求本来就很模糊），导致中间大家的理解不一样，所以才引发了争吵。
下面分别说一下：
第1个问题是页面参数的防篡改（指绕过页面上的输入限制，不是说有个输入框，随便可以输入100或1000这种，这不叫篡改），攻击目标是页面，这个基本上是没有办法的，除非你自己开发个客户端或者控件，所有业务界面都不是html的，否则有很多工具（比如IE8自带的开发人员工具）可以直接修改页面元素，这样的话加密之类的方法就不管用了，因为加密是之后的操作。
第2个问题是请求参数的防篡改，攻击目标是URL（包括get和post，post可以模拟），这个可以通过对关键参数加密后在服务端验证解决，但密钥的存取是个问题，尽量减少或避免在浏览器和服务器间传输密钥，最好是通过控件而不是js进行加密，而且密钥最好是动态的（比如取sessionID+页面URL）。
其实这类问题最好的办法还是一方面在设计阶段注意减少攻击点，另一方面必须对所有关键业务参数采用服务端验证，因为任何客户端手段都可能被绕过，是不靠谱的，而不管你怎么篡改，只要我在服务端做了必要的验证，就能保证你做的是无用功。以银行系统的“积分兑换”为例，如果兑换商品所花费的积分作为兑换请求的参数，这种设计就是错误的，因为别人可能从页面或请求中修改积分，好的设计是传商品编号，并在服务端验证当前用户是否满足兑换该商品的条件并获取商品的积分。

调试易

如果防止手动篡改请求参数

解决方案 »