Do I need to use `[ValidateAntiForgeryToken] and @Html.AntiForgeryToken()` on all my pages?

Question

All my project's page need authentication.. And Normally I dont use [ValidateAntiForgeryToken] and @Html.AntiForgeryToken() on my Controller and View.. Only login page has it..

1. What are they [ValidateAntiForgeryToken] and @Html.AntiForgeryToken()??
2. Do I need to use them??
3. Which cookieless I have to use??

My web.config's part like this;

<authorization>
  <deny users="?" />
</authorization>
<authentication mode="Forms">
  <forms loginUrl="~/User/Login" timeout="30" cookieless="UseDeviceProfile" name="AbosSMSP" />
</authentication>

My error like this;

Kareem

Answer 1

Think of the antiforgerytoken is a way of ensuring that the request that is coming to a post action is actually one that originated from your outputted view. It stops cross site scripting attacks and i think it handles post replay attacks too.

Securing the front door to your application is a good start, it stops people having their data stolen by brute force, however, it doesn't stop all forms of attacks. things like social engineering and phishing can let someone in to your site without them breaking the login page.

Once in, there are all sorts of nastiness that they can get up to, so look at the OSWAP recommendations and see if there are any other attacks that you might be vulnerable to. http://www.ergon.ch/fileadmin/doc/Airlock_Factsheet_OWASP_en.pdf

If in doubt, you can have your site pen tested by ethical hackers for a few hundred stirling, if you are looking after sensitive data, then i would recommend that, as they will pull up things that you might not even think of.

My top tips for security

1. Antiforgerytoken on the login page
2. Slow all authentication attempts down by at least a second (makes brute force impractical)
3. Implement an account lock out procedure on n amounts of invalid logons
4. Always use a generic error message on your failed logins to prevent hackers knowing which part of a login is wrong
5. Always encrypt your passwords in the db with a salt, the salt should be per user to prevent a rainbow attack on a stolen database
6. Always make sure that any data displayed or retrieved is valid for that user
7. Always use parameterised sql
8. Try and obfuscate the ids passed around in your urls and views to prevent modification or an attempt at a direct reference attack

Following that, I think you will cover off most of what a pen test would raise and set you on a good stead for a secure site

Davisdavison

It's off the topic of the OP, but this excellent list omits a fundamental to prevention of exploits including XSS (and therefore XSRF too): escaping all untrusted data for the execution context to which it is being output. The original source for that PDF has much additional wisdom: owasp.org/index.php/Top_10_2013-Top_10. On escaping, see "Am I Vulnerable To 'Cross-Site Scripting (XSS)'?" and "How Do I Prevent 'Cross-Site Scripting (XSS)'?" at owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS). – Wilder

P.S. While MVC is far better than WebForms at helping developers get escaping right, developer awareness remains critical. For example, it is up to the developer to wrap an untrusted JavaScript literal with @[Encoder/Ajax].JavaScriptEncode. See weblogs.asp.net/jgalloway/archive/2011/04/28/…. More generally, see the links under "Securing ASP.NET MVC applications" at msdn.microsoft.com/en-us/library/gg416514(v=vs.108).aspx. – Wilder

Do not encrypt passwords, they should always be hashed using a slow hashing mechanism like PBKF2 – Mustee