runtime loading of ValidateAntiForgeryToken Salt value

Question

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

The scenario is such that the app will be used by many customers. It's not terribly desirable to have the Salt known at compile time.

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

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

This leads to a compile-time exception suggesting that the Salt must be a const at compile time.

An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type

How can I modify the application to allow for a runtime loading of the Salt so that the app doesn't have to be re-salted and recompiled for each customer?

Consider that the Salt won't change frequently, if at all, thereby removing the possibility of invalidating form

Pyrazole

As Levi the Microsoft MVC security guys states, you don't need to do this. – Smithereens

Answer 1

I had the requirement to have different salts for different customers. In this case, I used Dixin's solution for injecting the salt at runtime.

Anti Forgery Request Recipes For ASP.NET MVC and AJAX at the section titled "Specify non-constant salt in runtime".

Decorate your 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.
}

Pyrazole

Answer 2

The Salt property is meant to be a compile-time constant. It's simply a way to link a particular form to a particular action method. For example, if you have a login form, you may wish to use the salt "Login" for this form so that a token that was valid for the login form can't be used for the change password form, etc.

In all cases, the app's machine key is automatically used as an additional salt value. So an anti-XSRF token for one application can't be used for another application, even if both salt values read "Login". The machine key is settable in the Web.config <machineKey> section.

Longitudinal

If I have a login form I don't need anti-forgery protection at all, do I? Because user is not yet authenticated and there is nothing yet to protect from. – Toinette

If you do not protect the login form, you are potentially open to Login CSRF. See en.wikipedia.org/wiki/CSRF#Forging_login_requests for more information. (Edit: the 'Salt' property has been removed from MVC 4 since most applications do not need it. See docs for more info if you were using it.) – Longitudinal

Thanks, interesting. But according to the article it's possible only in context of Flash (crossdomain.xml), regular sites aren't affected? – Toinette

Login CSRF doesn't require Flash. Including a crossdomain.xml file will prevent Flash-based exploits (which is why it is under the 'Countermeasures' heading), but an attacker can still perform regular CSRF (and login CSRF) attacks using ordinary Javascript. – Longitudinal

Sorry, I don't understand. CSRF is "a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts". To be trusted a user must be authenticated. Can you please share a link where the attack on regular login/password form is described in details? – Toinette