Design Principles
Several important principles apply to the guidance instructions provided in the following chapters. You should learn these principles and apply in your application design:
• Principles with minimal privileges. The process running scripts or execution code should run as much as possible of the least amount of permissions, so that the possible damage may be caused when the process is safe. If the malicious user is trying to inject the code into a server process, the permissions granted to this process will greatly determine the type of operation that the user can perform. The code that needs more trust (and higher privileges) should be isolated from different processes. The ASP.NET team consciously decides that the ASP.NET account (using an ASPNET account) is implemented in the original version of the .NET framework in the .NET framework. However, in the .NET framework test version, ASP.NET is run as a SYSTEM, from essentially a less secure setting. • Use a deep defense. Set check points in each layer of the application and each subsystem. The checkpoint is the gateway guard, which ensures that only authenticated and authorized users can access the next downstream layer. • Do not trust user input. The application should thorough all user inputs, and then perform operations according to user input. Verification may include screening special characters. This preventive measures have protected applications for applications to use in situations where the user is surprisingly incurred by the user. Common examples include SQL injection attacks, script injection and buffers overflow. • Use the default security settings. Developers often use only low security settings to make the application run. If the features needed to make you have to reduce the default security settings or change these default security settings, please change the consequences of the previous test changes and understand the hidden dangers that may be brought. • Do not guarantee security by hidden. Try using confused variables to hide confidential information or store them in unused file locations, these methods cannot provide security. In the "Hide" game, it is best to use platform functions or to protect data using the proven technology. • Check at the gate. You don't have to pass the security context of the user to the backend to perform an authorization check. Typically, this approach is not the best choice in a distributed system. In the gateway checking client means granting user permissions in the first authentication point (for example, within a web application on the web server) and determines the resources and operations that allow users to access (may be provided by the downstream service). If you design a reliable authentication and authorization strategy in the gatek, you don't have to delegate the original security context all the way to the application data layer. • Assume that the external system is an unsafe system. If the external system is not owned by you, don't assume that someone guarantees security. • Reduce the surface area. Avoid disclosure of information that does not require public. If this information is disclosed, it is possible to further cause a vulnerability. At the same time, the way to handle errors must be appropriate. When returning an error message to the end user, do not disclose any information that does not require public. • Display error messages in a secure way. If the application fails, you must protect your confidential data. At the same time, do not provide too detailed data in the error message, that is, do not provide any detailed information that helps attackers discover application vulnerabilities. The detailed error message should be written to the Windows event log. • Don't forget your security program to be restricted by the weakest link. Considering safety, the security of all layers of the application should be considered. • Disable unused content. You can remove some potential attack points by disabling modules and components that applications and components. For example, if the application does not use an output cache, the ASP.NET output cache module should be disabled. In this way, the application will not be threatened even in the module.
