ValidateAntiForgeryToken Salt Value Loading Time

Question

Consider an ASP.NET MVC application using the Salt parameter in the [ValidateAntiForgeryToken] directive.

The scenario is that the application will be used by many clients. It is not very desirable to have Salt at compile time.

The current strategy is to find the Salt value in the web.config file.

 [ValidateAntiForgeryToken(Salt = Config.AppSalt)] //Config.AppSalt is a static property that reads the web.config. 

This throws an exception at compile time, assuming that the Salt value must be const at compile time.

The attribute argument must be a constant expression, a typeof expression, or an array creation expression type attribute attribute

How can I change the application to allow Salt to load at runtime so that the application does not need to be re-salted and recompiled for each client?

Please note that Salt will not change often, if at all, thereby eliminating the possibility of form cancellation

Answer 1

I had a requirement to have different salts for different clients. In this case, I used Dixin solution for salt injection at runtime.

Anti Forgery Request Recipes for ASP.NET MVC and AJAX in the section titled " Specify a volatile salt at runtime ."

Decorate the controllers with a new attribute:

 [ValidateAntiForgeryTokenWrapper(HttpVerbs.Post)] public class ProductController : Controller { // Only HTTP POST requests are validated. } 

This new attribute is defined as:

 public class ValidateAntiForgeryTokenWrapperAttribute : FilterAttribute, IAuthorizationFilter { public ValidateAntiForgeryTokenWrapperAttribute(HttpVerbs verbs) { this._verbs = new AcceptVerbsAttribute(verbs); this._validator = new ValidateAntiForgeryTokenAttribute() { //load from web.config or anywhere else Salt = Configurations.AntiForgeryTokenSalt }; } // Other members. } 

Answer 2

The Salt property means compile time constant. This is just a way to associate a specific form with a specific method of action. For example, if you have a login form, you can use the Login salt for this form so that the token valid for the login form cannot be used for the shift password form, etc.

In all cases, the application machine key is automatically used as an additional salt value. Thus, the anti-XSRF token for one application cannot be used for another application, even if both salt values ​​are read “Input”. The machine key can be set in the Web.config <machineKey> section.