编码/混淆 HTTP 参数 [英] Encode/obfuscate HTTP parameters

问题描述

我们目前正在开发一个非常简单的 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

For instance, the url looks like /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 可以简单地在浏览器栏中更改为 user=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).

所以，总结一下:

1. 混淆的安全性不是完全安全.
2. 你不能相信用户数据，即使它是模糊的.验证您的数据.
3. 使用安全通信渠道 (SSL)有助于阻止其他相关威胁.
4. 你应该放弃你的方法并做正确的事情.正确的事情，在你的情况，可能意味着添加一个身份验证机制防止用户使用的特权系统从访问他们不是的东西有幸看到——包括他们可能会尝试访问的东西篡改 GET 参数.加里R 的回答，以及 Dave 和 Will 的评论这个在头上.

1. Security by obfuscation isn't security at all.
2. You can't trust user data, even if it is obscured. Validate your data.
3. Using secure communication channels (SSL) helps block other related threats.
4. You should abandon your approach and do the right thing. The right thing, in your case, probably means adding an authentication mechanism with a privilege system to prevent users from accessing things they aren't privileged enough to see - including things they might try to access by tampering with GET parameters. Gary R's answer, as well as Dave and Will's comment hit this one on the head.

这篇关于编码/混淆 HTTP 参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！