Search code examples
c#htmlasp.netformsburp

Is there a way to hide the posted Form data when the form submit is intercepted in Burp Suite or any similar tool

enter image description here

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?

Solution

  • 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.