有没有办法隐藏在表单提交上发回的键和值。因为这些键值可以被黑客使用安全测试工具（如 burp 套件）篡改？
问问题
2731 次
4 回答
2
虽然 HTTPS 用于保护传输中的数据，但没有实用的方法来防止用户篡改他们机器上的数据。现在几乎每个现代浏览器都有内置或附加的开发工具，允许用户暂停脚本执行、更改客户端脚本变量、修改 HTML 等等。
一种可以用于从客户端到服务器来回往返并且不会更改的数据（例如用户ID）的方法是在发送之前加密数据，然后在返回时解密服务器。另一种机制是获取所有预计不会更改的往返值并针对它们计算哈希值，该哈希值可以存储在页面上的隐藏字段中。然后当他们返回时，重新计算哈希并确保一切都匹配。然后“BobLimitedUser”无法通过在不破坏哈希的情况下操作 HTML 将他的用户名更改为“管理员”。
综上所述，基本事实很简单，您应该将来自不受您控制的系统的数据视为不受信任。最终输入验证应始终在服务器端执行（除了执行的任何客户端验证）。由于这种“双重验证”要求，对于复杂的验证例程，我实际上将使用 web 服务/AJAX 调用来执行客户端验证。然后我的客户端脚本和我的服务器代码可以简单地调用相同的例程，一次在提交期间和一次之后。
如果您采用在两端验证所有输入的方法（可以这么说），那么篡改确实不应该成为问题。如果 BobLimitedUser 想要操作 HTML，以便他可以将下拉值从一个值更改为他可以访问的另一个值，那么这就是浪费他的时间。如果他设法将某些内容更改为导致数据完整性或安全问题的值，那么服务器端验证就是要防止的。
简而言之
- 永远不要相信客户端脚本生成的任何东西。操作起来太容易了（或者甚至有一些旧脚本被浏览器缓存，变得过时，并破坏了某些东西）
- 客户端验证是为了响应性和可用性。服务器端验证用于数据完整性和安全性
- 不要将敏感信息传递给客户并相信它会完好无损地返回。如果必须，请使用加密来保护它，或使用散列来验证它。
- 甚至不必费心尝试在客户端加密/散列内容
- 在传输过程中使用 HTTPS 保护数据
- 实现安全相关错误的日志记录/警报。这样，如果您每天都收到 BobLimitedUser 试图利用您的应用程序的警报，您可以与您的 IT 安全部门联系并从他的机器中删除病毒，或者可以适当地处理他
数据验证是一个重要的讨论话题，我建议查看 OWASP 参考指南（此处复制的信息太多）：https ://www.owasp.org/index.php/Data_Validation
最后一点要考虑...如果您有一个客户端脚本应用程序，那么我假设您正在使用 AJAX 和 Web 服务来传输数据。无论您编写什么客户端脚本，是什么阻止了恶意用户简单地使用 Fiddler 之类的东西绕过客户端脚本和浏览器本身，直接向您的 Web 服务发送请求？确保安全性的唯一方法是验证服务器上的所有内容。
于 2015-10-21T18:37:30.610 回答
1
这假设您正在尝试阻止恶意用户修改值 - 如果您只是想阻止中间人攻击，请按照 Richard 的建议使用 HTTPS。
假设您希望用户能够发布值，简短的回答是否定的。
如果您不希望用户能够修改这些值，那么只需将它们存储在会话状态中并且不要将它们返回给用户（或者如果您需要它们在客户端和客户端之间传递，则从会话中读取它们）服务器）。
您还可以在服务器端验证返回的数据，即删除标签等。
本质上，您不能信任客户提供的数据。HTTPS 不会阻止恶意用户拦截请求并将其名字更改为“alert(1)”（例如）。
如果用户需要提供值，请检查它们是否安全并符合服务器端内容的规则。始终在服务器端检查授权等，不要信任用户提供的数据。
您无法阻止恶意用户在数据发送到您的服务器之前对其进行修改，但您可以在服务器使用数据之前对其进行验证。
于 2015-10-15T07:43:33.607 回答
1
当 Burp Suite 用作代理服务器时，它允许用户操纵通过它的流量，即 Web 浏览器（即客户端和 Web 服务器）之间的流量。这通常被称为中间人 (MITM) 类型的攻击架构。
我的建议是，您加密您希望在客户端保持不被篡改的数据，并将其单独存储在隐藏的表单字段中，然后再将其发布到服务器，然后在服务器端对其进行解密并将其与值进行比较（可能已被中间人篡改的数据）发布到服务器。
通过这种方式，您将知道是否对您想要保护的数据进行了任何更改。
PS：正如这里几乎所有答案中提到的，在这种情况下强烈建议使用 HTTPS。
于 2015-10-23T06:58:53.900 回答
0
使用 HTTPS 而不是 HTTP。HTTPS 将阻止中间人攻击并阻止攻击者看到纯文本。
于 2015-10-15T07:35:20.400 回答