0

Consider a protocol that allows clients to retrieve XML "forms" from a server. Forms are identified by a unique, randomly generated form ID that is embedded in the form. Clients fill out the form and submit it back to the server, communication uses relatively simple SOAP requests that contain the form in the SOAP body element.

I'm tasked with implementing the server side in this scenario. My problem is with malicious clients that might tamper with the embedded form ID (change it to some arbitrary value) and submit such a form back to the server. On the server side, a form with the modified form ID might already exist and would be overwritten by the submit, thus resulting in data loss.

My proposed solution would be to embed a PBKDF2 hash of the form ID alongside the plain text form ID. If the client tampers with either the plain or hashed ID the server would reject the submission. Is this a reasonably safe way to ensure form integrity? Is it a problem to disclose the hash to the client in this scenario (we are talking data integrity here, not confidentiality)? Are there any potential problems with my solution (e.g. use a better key derivation method)?

Any help is appreciated!

  • Your hash must incorporate something (e.g. a salt) that's not sent with the form. Shannon's maxim ("The enemy knows the system") says the malicious client can just recompute the hash if all the necessary information is in the form. – Bob Brown Sep 19 '14 at 13:22
1

If the salt used for PBKDF2 is of non-trivial length, say 128 bits, and the salt is stored with the form ID on the server (only), then this will allow you to check whether the form ID has been tampered with. There must be a secret component to the hash because of Kerckhoffs' principle, AKA Shannon's maxim. In this case, the salt, stored only on the server, is the secret.

  • Thank you for your answer, I'm going to try and implement the solution you proposed. Are there any recommended/required suggestions regarding salt length? I remember reading that salt length should equal hash length. I'm going to use SHA-256 as the underlying hash algorithm, so would a salt length of 32 byte suffice? – Michael Schmid Sep 22 '14 at 6:14
  • It ought to. I'm no cryptographer, but the idea is to make it computationally infeasible for the attacker to try all possible salts. A 256 bit salt should certainly do that. – Bob Brown Sep 22 '14 at 11:22
1

It sounds like your problem could be solved with anti-CSRF tokens or maybe you have them elsewhere already? See link below for details. Basically, with each form request a unique token would be sent and validated by the server. If the token is invalid, the request is blocked. The token would be unique, valid for that request only, and a malicious user would have a difficult time reproducing the token. Malicious users could tamper with whatever they want on the form, without that token it doesn't matter.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

  • Thanks for the link, interesting reading! As far as I understand anti-CSRF measures make most sense in the context of a "session", which does not exist in the scope of my protocol. However, the basic principle seems to be similar to Bob Brown's solution: generate a secret on the server and use it to validate incoming requests. – Michael Schmid Sep 22 '14 at 6:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.