Do I need to use `[ValidateAntiForgeryToken] and @

问题:

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;

回答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