Five common ASP. NET security defects

To ensure application security, you should start with the first line of code. The reason is simple. As the application grows, the cost of fixing security vulnerabilities also increases rapidly. According to research by the IBM Institute of Systems Sciences, fixing defects after software deployment costs 15 times that of detecting and eliminating defects during development.
To ensure the security of applications at minimal cost, developers should take more responsibilities in terms of code security and Attack resistance. However, to ensure program security from the initial stage of development, you must have the corresponding skills and tools, but not many developers can really master these skills and tools. Although it is a complicated process to learn to write secure code, it is best to complete it at university, internal training sessions, and industry meetings, as long as you have mastered the following five common ASP. NET application security defects and recommended correction solutions can take the lead to integrate indispensable security factors into the birth of the application.
1. Do not blindly trust user input
In Web application development, the biggest mistake for developers is to trust user input unconditionally. It is assumed that users (even malicious users) are always restricted by browsers and always interact with servers through browsers, this opens the door to attack Web applications. In fact, there are many tools for hackers to attack and operate Web sites, and they do not have to be limited to browsers, from the original interface (such as telnet) with the lowest level of character mode ), to CGI script scanners, Web proxies, and Web application scanners, malicious users may adopt many attack modes and methods.
Therefore, only by strictly verifying the legality of user input can we effectively resist hacker attacks. Applications can perform verification using multiple methods (or even methods with overlapping verification ranges), such as performing verification before authorizing user input to ensure that user input only contains valid characters, in addition, the content length of all input fields does not exceed the range (to prevent possible buffer overflow attacks). On this basis, other verification is performed to ensure that the data entered by the user is not only legal but reasonable. When necessary, you can not only adopt a mandatory length restriction policy, but also verify the input content according to the clearly defined feature set. The following suggestions will help you verify user input data correctly:
(1) Verification is always performed on all user input, and the verification must be performed on a reliable platform and on multiple layers of the application.