对 HTTP 参数进行编码/模糊处理

不，不要这样做。如果您可以在客户端代码中构建一些东西来混淆传输回服务器的数据，那么故意的黑客也可以。您根本无法信任发送到服务器的数据，无论您的官方客户端做什么。坚持转义客户端数据并根据服务器端的白名单对其进行验证。使用 SSL，如果可以，请将请求参数放在 POST 中，而不是 GET。

扩展编辑

您的困惑源于阻止用户篡改请求数据的目标，并且需要实施标准的安全措施。Web 应用程序的标准安全措施涉及结合使用身份验证、权限和会话管理、审核跟踪、数据验证和安全通信通道。

使用SSL并不能防止客户端篡改数据，但可以防止中间人看到或篡改数据。它还指示行为良好的浏览器不要在URL历史记录中缓存敏感数据。

看起来你有某种简单的Web应用程序，它没有身份验证，并在GET中传递控制它的请求参数，因此一些不懂技术的人可能会发现可以简单地在他们的浏览器栏中更改为，因此他们可以访问他们不应该看到的数据，或者做他们不应该做的事情。 你（或你的客户）混淆这些参数的愿望是天真的，因为它只会挫败最不懂技术的人。这是一个半生不熟的措施，您没有找到现有解决方案的原因是它不是一个好方法。您最好花时间实施一个体面的身份验证系统，并带有良好的审计跟踪措施（如果这确实是您所做的，请将Gary的答案标记为正确）。user=WorkerBeeuser=Boss

所以，总结一下：

1. 混淆的安全性根本不是安全性。
2. 您不能信任用户数据，即使它被遮挡了。验证数据。
3. 使用安全通信通道 （SSL） 有助于阻止其他相关威胁。
4. 你应该放弃你的方法，做正确的事情。在你的例子中，正确的做法可能意味着添加一个带有特权系统的身份验证机制，以防止用户访问他们没有足够的特权来查看的内容 - 包括他们可能尝试通过篡改GET参数来访问的内容。Gary R的回答，以及Dave和Will的评论都击中了这个。

如果您的目标是“减少空闲用户发送任意数据的机会”，那么我会尝试另一种更简单的方法。创建私有加密密钥并将其存储在应用程序服务器端。每当应用程序生成 url 时，请使用专用加密密钥创建 url 的哈希，并将该哈希放入查询字符串中。每当用户请求 URL 中包含参数的页面时，请重新计算哈希并查看它是否匹配。这将使您确定应用程序计算了 url。不过，这将使查询字符串参数保持可读。在伪代码中，

SALT = "so9dnfi3i21nwpsodjf";

function computeUrl(url) {
  return url + "&hash=" + md5(url + SALT );
}

function checkUrl(url) {
  hash = /&hash=(.+)/.match(url);
  oldUrl = url.strip(/&hash=.+/);
  return md5(oldUrl + SALT ) == hash;
}