ASP.NET MVC ValidateAntiForgeryToken — can it be replaced with authorization check & referrer check?

Question

In ASP.NET MVC there is a ValidateAntiForgeryToken attribute, that enables cross-site scripting defence.

Is it possible to replace this mechanism with

• authorization check, including checking that resource, that is being manipulated, belongs to current user;
• referrer check, that will forbid AJAX web api requests from external hosts;
• inhibition of site hosted in iframe?

Answer 1

This does not prevent cross site scripting, only cross site request forgery.

authorization check, including checking that resource, that is being manipulated, belongs to current user;

No, because the resource does belong to the current user, it is only the request that has not been willingly made by the current user.

e.g. say on your website www.foo.com you have the following URL that will delete the user's account.

www.foo.com/DeleteAccount

Your user is logged into www.foo.com. Now say your user visits www.evil.com which includes the following image tag on the page.

<img src="http://www.foo.com/DeleteAccount" />

This will make a request to your page and delete the user's account because the DeleteAccount resource will have checked authorisation via cookies and determined that the user is indeed authorised because the auth cookie was supplied with the request.

referrer check, that will forbid AJAX web api requests from external hosts;

Yes, this is a valid check although it is weaker than the method of using the Anti Forgery Token as mentioned in your question.

The OWASP CSRF Cheat Sheet states

Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check. It should be noted that GET requests should never incur a state change as this is a violation of the HTTP specification. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.

Also note that sometimes the referer isn't always passed as the user may be using privacy software that removes the header.

inhibition of site hosted in iframe?

This can be a valid defence for widgets that you host to be included on other sites.

e.g. www.bar.com could include your widget on their page via the use of a script tag:

<script src="//www.foo.com/widget.js"></script>

In order to prevent www.bar.com from submitting the form within your widget, your JavaScript code would document.write an IFrame into the page and then include your content within that. The Same Origin Policy will prevent the IFrame content from being read by the parent page and your form could not then be submitted by the site that includes your widget. However, here you may need a manual confirmation window to pop up in the case of any clicks to prevent click jacking attacks (e.g. if you had a like button (similar to Facebook) and you wanted to prevent fake likes from the including page submitting your form automatically).

OWASP Recommendation

The OWASP Recommendation is to use the Synchronizer Token Pattern which is the one implemented by ASP.NET MVC with ValidateAntiForgeryToken.