Is there a way to hide the posted Form data when t

问题:

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?

回答1:

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.

回答2:

This assumes you are trying to prevent a malicious user from modifying values - if you just want to prevent man in the middle attacks, use HTTPS as Richard suggests.

Assuming you want the user to be able to post values, the short answer is no.

If you don't want the user to be able to modify these values, then just store them in session state and don't return them to the user (or read them back from session if you need them to be passed between the client and the server).

You can also validate the returned data on the server side, i.e. remove tags etc.

Essentially, you can't trust client supplied data. HTTPS won't stop a malicious user intercepting the request and changing their firstName to "alert(1)" (for example).

If the user needs to supply values, check they are safe and match your rules for content on the server side. Always check authorization etc. on the server side, don't trust user supplied data.

You can't stop a malicious user from modifying data before it's sent to your server, but you can verify data before your server uses it.

回答3:

When Burp Suite is used as a proxy server, it allows the user to manipulate the traffic that passes through it, i.e. between the web browser i.e. client and the web server. This is typically referred to as a Man-in-the-middle (MITM) type attack architecture.

My suggestion is that you encrypt the data that you would want to keep untampered on the client side and store it separately in a hidden form field before posting it to the server, and then decrypt it on the server side and compare it with the value(data that may have been tampered with by a Man-in-the-middle) that was posted to the server.

This way you would know if there was any change made to the data you would want to keep safe.

P.S: As mentioned in almost all the answers here, use of HTTPS is highly recommended in such cases.

回答4:

Use HTTPS instead of HTTP. HTTPS will stop man-in-the-middle-attacks and prevents an attacker from seeing the plain text.