问题描述
我们目前正在开发一个非常简单的Web应用程序，我们希望混淆（什么是正确的术语？）或以某种方式编码请求参数，这样我们就可以减少机会空闲用户发送任意数据。
We are currently working on a very simple Webapp, and we would like to "obfuscate" ( what would be the right term? ) or encode somehow the request parameter, so we can reduce the chance an idle user from sending arbitrarily data.
例如，网址看起来像 / webapp？user = Oscar& count = 3
我们希望得到类似： / webapp？data = EDZhjgzzkjhGZKJHGZIUYZT 并在服务器中使用真实请求信息解码该值。
We would like to have somthing like: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT and have that value decoded in the server with the real request info.
在开始实施这样的事情之前（可能做错了）我想知道是否还有什么可以做到的？
Before going into implementing something like this ourselves ( and probably doing it wrong ) I would like to know if there is something to do this already?
我们在服务器上有Java，客户端上有JavaScript。
We have Java on the server and JavaScript on the client.
推荐答案
不，不要这样做。如果你可以在客户端代码中构建一些东西来混淆传输回服务器的数据，那么一个故意的黑客也是如此。无论您的官方客户端做什么，您都无法信任发送到您服务器的数据。 坚持转发客户端数据并根据服务器端的白名单进行验证。使用SSL，如果可以，请将您的请求参数放入POST而不是GET。
No, don't do this. If you can build something in your client code to obfuscate the data being transmitted back to the server, then so can a willful hacker. You simply can't trust data being sent to your server, no matter what your official client does. Stick to escaping client data and validating it against a whitelist on the server side. Use SSL, and if you can, put your request parameters in a POST instead of GET.
扩展编辑
您的困惑源于阻止用户篡改请求数据的目标，需要实施标准安全措施。 Web应用程序的标准安全措施涉及使用身份验证，权限和会话管理，审计跟踪，数据验证和安全通信渠道的组合。
Your confusion stems from the goal to block users from tampering with request data, with the need to implementing standard security measures. Standard security measures for web applications involve using a combination of authentication, privilege and session management, audit trails, data validation, and secure communication channels.
使用SSL并不能阻止客户端篡改数据，但它确实阻止了中间人查看或篡改数据。它还指示行为良好的浏览器不要在URL历史记录中缓存敏感数据。
Using SSL doesn't prevent the client from tampering with the data, but it does prevent middle-men from seeing or tampering with it. It also instructs well-behaved browsers not to cache sensitive data in the URL history.
您似乎有某种简单的Web应用程序没有身份验证，并且传递请求参数在GET中控制它，因此一些非技术精明的人可能会发现 user = WorkerBee 可以简单地更改为用户= Boss 在他们的浏览器栏中，因此他们可以访问他们看不到的数据，或做他们不应该做的事情。 你的愿望（或顾客的愿望）混淆这些参数是天真的，因为它只会削弱技术上最不精明的人。这是一个半生不熟的措施，你没有找到现有解决方案的原因是它不是一个好的方法。你最好花时间实现一个体面的认证系统和审计跟踪（如果这确实是你做的那样，请标记正确）。
It seems you have some sort of simple web application that has no authentication, and passes around request parameters that control it right in the GET, and thus some non-technically savvy people could probably figure out that user=WorkerBee can simply be changed to user=Boss in their browser bar, and thus they can access data they shouldn't see, or do things they shouldn't do. Your desire (or your customer's desire) to obfuscate those parameters is naïve, as it is only going to foil the least-technically savvy person. It is a half-baked measure and the reason you haven't found an existing solution is that it isn't a good approach. You're better off spending time implementing a decent authentication system with an audit trail for good measure (and if this is indeed what you do, mark Gary's answer as correct).
所以，把它包起来：
- 通过模糊处理的安全性根本不是
安全性。 - 您不能信任
用户数据，即使它被遮挡了。
。 - 使用安全通信渠道（SSL）
有助于阻止其他相关威胁。 - 你
应该放弃你的方法并做正确的
。正确的事情，在
你的情况下，可能意味着添加
身份验证机制和
权限系统，以防止用户
访问他们不是
特权的东西看 - 包括
他们可能试图通过
篡改GET参数来访问的东西。 ，以及Dave和Will的评论命中
这个就好了。
- Security by obfuscation isn'tsecurity at all.
- You can't trustuser data, even if it is obscured.Validate your data.
- Using secure communication channels (SSL)helps block other related threats.
- Youshould abandon your approach and dothe right thing. The right thing, inyour case, probably means adding anauthentication mechanism with aprivilege system to prevent usersfrom accessing things they aren'tprivileged enough to see - includingthings they might try to access bytampering with GET parameters. GaryR's answer, as well as Dave and Will's comment hitthis one on the head.
这篇关于编码/混淆HTTP参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！