Preface: Protecting the security of web applications seems like a chore. This must-do work does not bring much fun, but in order to avoid embarrassing security vulnerabilities, the security of the program usually has to be done.
1. Web Forms Developers
(1) Because MVC does not provide many automatic protection mechanisms like Web Forms to protect the page from malicious users, read this blog to understand this issue. A more explicit statement is: Web Forms is committed to keeping applications from attacks. For example:
1) The server component HTML encoding of displayed values and features to help prevent XSS attacks.
2) Encrypt and verify the attempted state, thereby helping to prevent tampering with submitted forms.
3) Request verification (%@pagevalidaterequest=”true”%) intercepts data that looks malicious and warns (this is the protection enabled by the MVC framework by default).
4) Event verification helps the organization inject attacks and submit invalid values.
(2) Turning to MVC means that the handling of these problems will fall on the shoulders of programmers—it may cause panic for some, but may be a good thing for others.
(3) If you think that the framework "should handle this kind of thing", then there is indeed a framework that can handle this kind of thing, and it handles it well, it is web forms. However, the price is to lose some control over the abstraction level introduced by web froms.
(4) MVC provides more control over tags, which means programmers have to bear more responsibilities. It should be clear that MVC provides many built-in protection mechanisms (for example, by default, using HTML auxiliary methods and Razor syntax for HTML encoding and request verification and other functional features).
MVC Developer
(1) For applications with security risks, the main excuse is that developers lack sufficient information or understanding. We want to change this situation, but we also realize that no one is perfect, and there will always be times of negligence. In view of this, please remember the following tips.
1) Never trust any data provided by users
2) Whenever data is rendered as user input, please HTML encoding it (if the data is displayed as a characteristic value, HTML encoding should be performed)
3) Consider those parts of the website that allow anonymous access, and those parts require authenticated access.
4) Don't try to purify the user's HTML input yourself—or you will encounter failure.
5) Use HTTP-only cookies when you do not need to access cookies through client scripts.
6) It is highly recommended to use the AntiXss library (/AntiXSS)。
(2) At the same time, the construction of the application is based on the assumption that only a specific user can perform certain operations and other users cannot perform these operations.
Note: Here we will introduce how to use the security features in MVC to execute application functions such as authorization, and then introduce how to deal with common security threats.