当表单提交在Burp Suite或任何类似工具中被拦截时，是否有办法隐藏发布的表单数据？ [英] Is there a way to hide the posted Form data when the form submit is intercepted in Burp Suite or any similar tool
问题描述
有没有办法隐藏在表单提交中发布的键和值。黑客使用安全测试工具（如burp套件）可以篡改关键值？
解决方案尽管HTTPS用于保护数据在传输中，没有实际的方法来防止用户篡改他们机器上的数据。几乎每个现代浏览器都有内置或附加开发者工具，允许用户暂停脚本执行，更改客户端脚本变量，修改HTML等等。
<一种可以用于从客户端到服务器往返往返并且不会改变（例如用户ID）的数据的方法是在发送之前加密数据，然后在解密时解密返回到服务器。另一种机制是将所有往返值都预计不会发生变化，并计算可能存储在页面隐藏字段中的散列值。然后，当他们返回时，重新计算散列并确保一切都匹配。然后，BobLimitedUser无法通过操纵HTML而将其用户名更改为Administrator，而不会破坏散列。所有这些都说明了这一点，根本的事实是，您应该将来自不受您控制的系统的数据视为不可信。最终输入验证应始终在服务器端执行（除了执行任何客户端验证外）。由于这种双重验证的要求，对于复杂的验证例程，我实际上会使用webservice / AJAX调用来执行客户端验证。然后，我的客户端脚本和我的服务器代码可以简单地调用相同的例程，在提交期间和之后一次。
如果采取这种方法，您将验证所有输入结束（可以这么说），然后篡改真的不应该是一个问题。如果BobLimitedUser想操纵HTML，以便他可以将一个下拉值从一个值更改为另一个值，那么这是他浪费的时间。如果他设法将某些东西改变为导致数据完整性或安全问题的值，那么服务器端验证就是为了防止这种情况发生。
简而言之， p>
- 永远不要相信客户端脚本产生的任何东西。它很容易操作（或者甚至让一些旧的脚本被浏览器缓存，变得过时并破坏某些内容）。
- 客户端验证是为了响应和可用性。服务器端验证用于数据完整性和安全性
- 不要将敏感信息传递给客户端，并相信它会完好无损地返回。如果你必须的话，那么使用加密来保护它，或者使用哈希来验证它。
- 甚至不打扰客户端加密/哈希的东西
- 在运输过程中使用HTTPS保护数据
- 实施与安全相关的错误的记录/警报。这样，如果您每天收到BobLimitedUser试图利用您的应用程序的警报，则可以与IT安全部门通话，并从病毒中删除病毒，或者正确处理病毒。
数据验证是一个很大的讨论话题，我建议您查看OWASP参考指南（这里仅仅是复制太多信息）：
最后一点要思考......如果您有一个客户端脚本应用程序，那么我假设您使用AJAX和Web服务来传输数据。无论您编写什么客户端脚本，是什么阻止恶意用户简单地使用Fiddler之类来绕过客户端脚本，而是浏览器本身直接将请求发送到Web服务？确保安全性的唯一方法是验证服务器上的所有内容。
Is there a way to hide the keys and values that are posted back on form submit.As these key values can be tampered with by the Hacker using Security testing tools such as burp suite?
While HTTPS is used to secure data in transit, there is no practical way to prevent a user from tampering with data on their machine. Pretty much every modern browser now has built-in or add-on developer tools that allow a user to pause script execution, change client script variables, modify HTML, and so on.
One method that CAN be used for data that is round-tripped back and forth from the client to the server and doesn't change (such as a UserID) would be to encrypt the data prior to sending, and then decrypt when it returns to the server. Another mechanism would be to take all of your round-trip values that aren't expected to change and compute a hash against them which could be stored in a hidden field on the page. Then when they return, recompute the hash and make sure that everything matches up. Then "BobLimitedUser" couldn't change his username to "Administrator" by manipulating HTML without breaking the hash.
All of that being said, the underlying fact is simply that you should consider data coming from a system not under your control as untrusted. Final input validation should always be performed server-side (in addition to any client-side validation performed). Because of this "double validation" requirement, for complex validation routines, I'll actually use a webservice/AJAX call to perform the client-side validation. Then my client script and my server code can simply call the same routine, once during and once after submission.
If you take the approach that you will validate all input at both ends (so to speak), then tampering really shouldn't be an issue. If BobLimitedUser wants to manipulate HTML so he can change a dropdown value from one value to another value he has access to, that is his time to waste. If he manages to change something to a value that causes data integrity or security issues, that is what the server-side validation is there to protect against.
In Short
- Never trust anything generated by client script. It is simply too easy to manipulate (or even have some old script get cached by the browser, become outdated, and break something)
- Client side validation is for responsiveness and usability. Server side validation is for data integrity and security
- Don't pass sensitive information to the client and trust it to come back intact. If you must, then use encryption to protect it, or hashing to validate it.
- Don't even bother trying to encrypt/hash stuff client-side
- Do use HTTPS to protect data during transport
- Implement logging/alerting of security related errors. That way, if you get alerts every day that BobLimitedUser is attempting to exploit your app, you can talk to your IT security department and either get the virus removed from his machine, or he can be dealt with appropriately
Data validation is a big topic of discussion, and I would recommend reviewing the OWASP reference guide (simply too much information to replicate here): https://www.owasp.org/index.php/Data_Validation
One last bit to think on... if you have a client-script application, then I assume you are using AJAX and web services to transmit data. Regardless of what client script you write, what prevents a malicious user from simply using something like Fiddler to bypass not only the client script, but the browser itself, to send requests directly to your web service? The only way to ensure security is to validate everything at the server.
这篇关于当表单提交在Burp Suite或任何类似工具中被拦截时，是否有办法隐藏发布的表单数据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
