Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you are doing this to trust code that you sent to the client browser, then change direction. You really don't want to trust user input, which includes calls from js that you sent to the browser. The logic on the server should be made so that nothing wrong can be done through there. That said, asp.net uses a signed field, you might want to go that way if absolutely necessary.</p> <p>Expanding a bit: Asp.net tamper-proofs the viewstate, which is sent as a html hidden field (depending on the configuration). I am sure there are better links as reference, but at least it is mentioned on this one: <a href="http://msdn.microsoft.com/en-us/library/ms998288.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/ms998288.aspx</a></p> <blockquote> <p>validation. This specifies the hashing algorithm used to generate HMACs to make ViewState and forms authentication tickets tamper proof. This attribute is also used to specify the encryption algorithm used for ViewState encryption. This attribute supports the following options:</p> <ul> <li>SHA1–SHA1 is used to tamper proof ViewState and, if configured, the forms authentication ticket. When SHA1 is selected for the validation attribute, the algorithm used is HMACSHA1.</li> </ul> </blockquote> <p>A link for the .net class for that algorithm <a href="http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx</a>.</p> <p><strong>Update 2:</strong> For tamper-proofing you want to sign the data (not encrypt it). Note that when using cryptography in general, you should really avoid using a custom implementation or algorithm. Regarding the steps, I would stick to:</p> <ul> <li>Assign a token to a JavaScript variable (generated server-side). <em>You include info to identify the request and the exact date&amp;time where it was issued. The signature will validate the server side application issued the data.</em></li> <li>Identify double submits if appropriate.</li> </ul> <p>That said, the reason asp.net validates the viewstate by default, is because devs rely on info coming in there as being handled only by the application when they shouldn't. The same probably applies for your scenario, don't rely on this mechanism. If you want to evaluate whether someone can do something use authentication+authorization. If you want to know the ajax call is sending only valid options, validate them. Don't expose an API at granularity level than the one where you can appropriately authorize the actions. This mechanism is just an extra measure, in case something slipped, not a real protection.</p> <p>Ps. with the HMACSHA1 above, you would instantiate it with a fixed key</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload