RE: Question on input validation

["Scovetta, Michael V" <Michael.Scovetta () ca com>]

You can certainly and and receive a salted hash of the expected (static) data, but
for user-defined input, you can't hash on the client side (the strength of the 
hash is the secret salt).

For instance:
  http://server?action=choosename&name=mike

You can certainly validate that 'choosename' is sent back, but you can't send
a salted hash of 'mike' because you don't know it beforehand. 

Or did I not understand your question?

Michael Scovetta

-----Original Message-----
From: Noah Gray [mailto:ngray () lightport com]
Sent: Tuesday, September 23, 2003 2:43 PM
To: webappsec () securityfocus com
Subject: Question on input validation


Input please:

Would it be considered any less secure to, rather than validate input parameter types, instead synchronous-key-hash the 
parameters and compare the hash on the receiving side?

For instance:
FormA Gets/Posts to FormB with the following parameters:
 - AuthorizedResourceID
 - PriviledgedActionType

Using the Input and Authorization checking, one must check the types (string/int, not null, greater than 0, etc). 
Additionally, one must validate the users permission to the Authorized resource, as well as their permission to execute 
the specified permission.

However, using a synch-key hash, such as HMAC-SHA1, I could simply pass a third parameter, ParmHash, that the receiving 
script could also generate and compare using a shared key. Doing this, I needn't worry about the user's permission to 
do anything that is signed from my calling script, nor about the input's validity. I can save a round-trip to the 
database to do any permission lookup, thus making the application more efficient. The only issue is that links or form 
posts must be pre-generated by the server, and clearly this would not be possible in every situation.

The question is, how, if at all, might this be a bad idea?

Regards, 
Noah Gray 
Application Developer 
LightPort Advisors
ngray at lightport.com