我们目前正在开发一个非常简单的 Web 应用程序，我们希望“混淆”(什么是正确的术语？)或以某种方式对请求参数进行编码，这样我们就可以减少机会空闲用户发送任意数据。
例如，url 看起来像 /webapp?user=Oscar&count=3
我们想要这样的东西:/webapp?data=EDZhjgzzkjhGZKJHGZIUYZT 并在服务器中使用真实的请求信息对该值进行解码。
在我们自己实现类似的东西(并且可能做错了)之前，我想知道是否已经有东西可以做到这一点？
我们在服务器端使用 Java，在客户端使用 JavaScript。
最佳答案
不，不要这样做。如果您可以在客户端代码中构建一些东西来混淆传输回服务器的数据，那么故意的黑客也可以。无论您的官方客户端做什么，您都不能相信发送到您服务器的数据。 坚持转义客户端数据并根据服务器端的白名单对其进行验证。使用 SSL，如果可以，请将请求参数放在 POST 而不是 GET 中。
扩展编辑
您的困惑源于阻止用户篡改请求数据的目标，以及实现标准安全措施的需要。 Web 应用程序的标准安全措施包括使用身份验证、特权和 session 管理、审计跟踪、数据验证和安全通信 channel 的组合。
使用 SSL 并不能防止客户端篡改数据，但它确实可以防止中间人看到或篡改数据。它还指示行为良好的浏览器不要在 URL 历史记录中缓存敏感数据。
您似乎拥有某种没有身份验证的简单 Web 应用程序，并在 GET 中传递控制它的请求参数，因此一些不懂技术的人可能会发现 user=WorkerBee 可以简单地在他们的浏览器栏中更改为 user=Boss，因此他们可以访问他们不应该看到的数据，或者做他们不应该做的事情。 您希望(或您的客户希望)混淆这些参数是天真的，因为这只会挫败技术最不精通的人。这是一个半生不熟的措施，您没有找到现有解决方案的原因是它不是一个好的方法。您最好花时间实现一个带有审计跟踪的体面的身份验证系统(如果这确实是您所做的，请将 Gary's answer 标记为正确)。
所以，总结一下:
- 混淆的安全性不是 完全安全。
- 你不能相信 用户数据，即使它是模糊的。 Validate your data .
- 使用安全通信 channel (SSL) 有助于阻止其他相关威胁。
- 你 应该放弃你的方法并做 正确的事情。正确的事情，在 你的情况，可能意味着添加一个 身份验证机制 特权系统，以防止用户 从访问他们不是的东西 有足够的特权看到 - 包括 他们可能会尝试访问的东西 篡改 GET 参数。 Gary R's answer , 以及 Dave 和 Will 的评论命中 这个在头上。
关于java - 编码/混淆 HTTP 参数，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4017757/