views:

1122

answers:

4

To protect a web application from query string manipulation, I was considering adding a query string parameter to every url which stores a SHA1 hash of all the other query string parameters & values, then validating against the hash on every request.

Does this method provide strong protection against user manipulation of query string values? Are there any other downsides/side-effects to doing this?

I am not particularly concerned about the 'ugly' urls for this private web application. Url's will still be 'bookmarkable' as the hash will always be the same for the same query string arguments.

This is an ASP.NET application.

A: 

I think is a good idea to add a parameter with a hash of all the other parameters. It prevents radically the querystring manipulation, but you have to think about the problem that means use those URLs in other pages of your application, send those URLs to the public or use them in any printed way. You need to have a very good way to order and to have them at hand speccially if those pages are not dynamically created, or if you just need to add those URLs by hand.

I don't see any other problem about it. Some one may tell you that the hash can be calculated, but you can play with the order of the parameters obtaining different hashes and making very difficult to guess.

backslash17
+4  A: 

I'm not sure this provides any sort of security. If a man-in-the-middle attacker wants to change the parameters, all he must do is change the query string and recompute the SHA-1 hash and send that request along to the server.

For example, the URL sent by the browser might be:

http://www.example.com/addUser.html?parameterA=foo&hash=SHA1("parameterA=foo")

If an attacker intercepts this, he can edit it in this way:

http://www.example.com/adduser.html?parameterA=bar&hash=SHA1("parameterA=bar")

Really, this boils down to the fact you can trust the hash only as much as the parameters themselves.

One way you could fix this would be if the user has a password that only he and the server knows, then it would be impossible for the attacker to recompute the hash if he changes the parameters. For example:

http://www.example.com/addUser.html?parameterA=foo&hash=SHA1("parameterA=foo"+"theuserpassword")

But don't put the password as one of the parameters in the URL :)

It is important to note that this isn't the state of the art for verifying the integrity of messages passed between two parties. What is used today is a form of the Hash-based Message Authenticion Code (HMAC) algorithm, which is pretty well described in HMAC, and definitively in RFC2104 and FIPS Pub 198-1.

Jeremy Powell
You can simply have a Salt for the Hash to prevent manipulation/man-in-the-middle etc.
Dead account
If you mean salts that are like /etc/passwd salts, then these don't provide any safety against mitm attacks. Salts are in general public knowledge and only serve to make it more difficult to reverse a hash using brute force attacks. The 'salt' (really the key in a keyed hash) must be secret in order to prevent the attacker from being able to change and recompute the digest. This is basically an authentication scheme, which generally requires some sort of shared secret knowledge before hand.
Jeremy Powell
I think as long as the salt is very random and kept secret, this will be an acceptable solution.
saille
For a *great* description of salts and how they're used in security, see this: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190
Jeremy Powell
Downvoted for reinventing HMAC poorly.
novalis
@novalis, you are right that this isn't state-of-the-art. My intention was to simply describe the concept of HMAC without confusing the discussion with padding. To clarify, I have added a paragraph noting this and referencing the proper RFC and NIST publications.
Jeremy Powell
A: 

You might consider using this little open source library:

http://www.codeproject.com/KB/aspnet/Univar.aspx

It uses a unique key for each client computer and comes with many other goodies.

Ziad
A: 

One major problem with this is that javascript would have to do client-side SHA calculations just to link to pages, this of course depends on how much you use JS but it shouldn't be unresonable to think that a get argument might include pageNo=1, and to have a 'jump to page' input box, this would be made difficult if you add a hash. You could store in a session (server side) anything that you really don't want manipulated.

tobyodavies