Security Guide Study Notes (1)

ArticleDirectory

• Authentication
• Authorization
• Secure Communication

I feel very lacking in website security, so I want to study it well, so I ran to the MS website to find information ~

Http://www.microsoft.com/china/technet/security/guidance/secmod01.mspx

I learned to keep some text ~

Article 1 Construct a secure distributed Web ApplicationProgramAnd a group of important security principles to be followed

The foundation for building secure distributed Web applications: authentication, authorization, and secure communication.

Any successful application security policy has a solid foundation, that is, the comprehensive use of identity authentication, authorization and secure communication mechanisms to protect the security and integrity of confidential data.

Authentication

Authentication can clearly identify the client of the application. The client may include end users, services, processes, or computers. In security terminology, authenticated clients are called subjects.

Authentication is performed on all layers of the distributed Web application. End users usually need to enter the user name and password for initial verification by the web application. Then, when the intermediate Application Server (if this type of server is included in the architecture) and the database server process end user requests, they perform authentication on the user to confirm and process the request.

In many applications, the downstream servers and components do not authenticate the end user. Instead, they authenticate the entity of the upstream application to understand the trust relationship, after you confirm that you can trust the upstream application to correctly verify the user and authorize the user, the request is forwarded.

Authorization

The authorization process is used to control which resources and operations can be accessed by authenticated clients. Resources include files, databases, tables, and rows, as well as registry keys, configuration data, and other system-level resources.

Many Web applications authorize clients to access open operations through methods, rather than directly accessing underlying resources, mainly considering scalability and ease of management. This means that it is still necessary to use platform-level security mechanisms such as Windows ACL to protect system-level resources. Many common application-level authorization schemes use roles to group users. users in the same Group share the same permissions in applications.

Secure Communication

Many applications transmit confidential data between the application layer, such as from the database server to the browser or vice versa. Confidential data includes bank account details, credit card numbers, and payroll data. In addition, when passing logon creden。 over the network, the application must also protect the security of these creden.

Secure Communication provides the following two functions:

Confidentiality. Confidentiality means to ensure that the data is private and confidential and will not be viewed by eavesdroppers who may use network monitoring software. Encryption is usually used for confidentiality purposes.

Integrity. Secure Communication channels must also ensure that data is protected to prevent accidental or deliberate (malicious) Modification of data during transmission. Integrity is usually achieved through the use of "Message AuthenticationCodeMessage authentication code (MAC.

As many unexpected information leaks and security vulnerabilities occur within the company's network, it is very important to apply secure communication technology inside and outside the firewall.

Various technologies and their main authentication and authorization methods are summarized.

. NET Web Application Security

A group of important security principles that should be followed when building distributed Web applications:

1. Adopt the principle of least privilege. Processes that run scripts or code should run with accounts with the least permissions as far as possible, resulting in possible damage caused by the time limit of process security hazards. If a malicious user tries to inject code into a server process, the permissions granted to the process determine the type of operations that the user can perform. Code requiring higher trust levels (and higher permissions) should be assigned to individual processes for isolation.
The ASP. NET Development Team is aware of this and is particularly set to run with an ASP. NET account with minimum permissions (using an ASPNET account. This change has been implemented in the initial version of. NET Framework. However, in the beta version, ASP. NET runs under the system account, which is essentially an insecure setting.

2. Use in-depth defense. Set checkpoints in each layer of the application and in each subsystem. Checkpoints are gateway guard, which ensure that only authenticated and authorized users can access the next downstream layer.

3. Do not trust user input. The application should thoroughly verify all user input and then perform operations based on user input. Verification may include filtering special characters. This preventive measure protects applications against users' accidental operation errors and deliberate attacks by injecting malicious commands into the system. Common examples include SQL injection attacks, script injection, and buffer overflow.

4. Use the default security settings. Developers often only use low-security settings to make the application program run. If the features required by the application make you have to reduce the security level of the default security settings or change these default security settings, test the consequences of the changes and learn the potential risks before the changes.

5. Do not hide to ensure security. These methods do not provide security when you try to use confusing variable names to hide confidential information or store them in uncommon file locations. These operations are similar to "hide and seek", and the best way is to use platform functions or proven technologies to protect data.

6. check at the gateway. You do not have to always pass your security context to the backend for authorization checks. This approach is usually not the best choice in distributed systems. The check client at the Pass refers to granting user permissions at the first authentication point (for example, within a web application on a Web server, determine the resources and operations that allow users to access (which may be provided by downstream services ).
If a reliable authentication and authorization policy is designed at the gateway, the security context of the original caller will not be delegated to the application data layer.

7. Assume that the external system is insecure. If the external system is not owned by you, do not assume that someone guarantees security for you.

8. Reduce the surface area. Avoid disclosing unnecessary information. If such information is disclosed, more security vulnerabilities may occur. At the same time, make sure that the error handling method is appropriate. When an error message is returned to an end user, do not disclose any information that does not need to be disclosed.

9. Display error messages securely. If the application fails, you must protect confidential data. At the same time, do not provide too detailed data in error messages, that is, do not provide any detailed information that helps attackers discover application vulnerabilities. Detailed error information should be written into the Windows event log.

10. Do not forget that your security level is restricted by the weakest link. When considering security, the security of all layers of the application should be taken into account.

11. Prohibited content. You can remove potential vulnerabilities by disabling modules and components that are not required by applications. For example, if the application does not use the output cache, the ASP. NET output cache module should be disabled. In this way, even if security vulnerabilities are discovered in this module, the application will not be threatened.