Asp.net| Security | procedure
In this chapter
Building Secure, distributed Web applications is an extremely challenging task. The security of user applications is constrained by the weakest link in the application, and distributed applications have many links. Users must have proven knowledge, a wide range of products and technologies, to enable all components of a distributed application to work together in a secure manner.
This chapter describes the basics of building Secure distributed Web applications: Authentication, authorization, and secure communications. Authentication, authorization, and secure communication. This chapter also describes a set of key security principles that users should focus on when building a distributed WEB application.
Goal
Use this chapter to:
•
Understand the meaning of terminology authentication, authorization, and secure communication in the context of this guide.
•
Understand the overall architecture of high-level asp.net Web applications. This means understanding the technologies that make up the architecture and the authentication, authorization, and secure communication options provided by each technology.
•
Understand the key security principles that form the basis of the rest of this guide.
Apply to:
This chapter applies to the following products and technologies:
•
Microsoft_ Windows_ XP or Windows Server and subsequent operating systems
•
Version 1.0 and later versions of the. NET Framework
•
asp.net 1.0
How to use this chapter
To get the maximum benefit from this chapter:
•
Users must be familiar with Microsoft's products and technologies, including Windows, Microsoft SQL server™2000, Internet information Services, the. NET framework, and enterprise-class service (COM +).
•
Users must have the experience of developing asp.net Web applications.
Content of this page
A brief summary of the principle of coordination design for the basic knowledge and technology of interconnection environment
Interconnect environment
If you already know how to build a secure application, can you apply the knowledge you have when you build a. NET Web application? In today's web-based advertising-based application environment, Web Services connect companies to companies, connect companies to customers, and applications are exposed to different programs, such as those exposed to intranets, extranets, and Internet users, Can you apply the knowledge you have in this application environment?
Consider some of the basic features of this interconnected environment:
•
The standards used by WEB services include the Simple Object Access Protocol (easy access Protocol,soap), Extensible Markup Language (extensible Markup Language,xml), and Hypertext Transfer Protocol (hypertext Transport Protocol,http), however, they basically use plain text to deliver potentially confidential information.
•
Internet Business-to-consumer applications Pass confidential data over the Web.
•
The Extranet business-to-business application blurs the trust line and allows other applications in the partner company to invoke the application.
•
Intranet applications also have risks in maintaining the confidentiality of payroll and human Resource (HR) applications. Such applications are especially vulnerable to attacks due to irresponsible administrators and some disgruntled employees.
Back to the top of the page
Basic knowledge
The security strategy for any successful application is based on a reliable approach that requires the combination of authentication, authorization, and secure communications to provide confidentiality and integrity of confidential data. It is important to define these core concepts before proceeding with the introduction. In the authentication and authorization chapter, we will show you how to combine various authentication and authorization mechanisms to provide a reliable security design.
Authentication
Authentication explicitly identifies the client of an application, and the client may include an end user, service, process, or computer. In the security language, the first point to be identified is the authenticated customer.
Authentication is performed across tiers of a distributed WEB application. The end user was initially authenticated by the WEB application and generally required a username and password. Subsequently, when an application server in the middle tier (if this layer is in the user's architecture) and the database server processes the end-user's request, they authenticate and process the request.
In many applications, downstream servers and components do not authenticate end users. They authenticate only to entities that are the upstream application, trust the application for proper authentication, and authorize the request before forwarding it.
Many of the authentication mechanisms that apply to ASP.NET application development will be discussed further in the "Security model for ASP. NET Applications" chapter.
Authorized
The authorization process manages the resources and operations that authenticated customers are allowed to access. Resources include files, databases, tables, rows, and system-level resources, such as registry keys and configuration data.
First, many WEB applications authorize access through methods rather than directly to the operations of those resources for measurable and manageable resources. That is, the use of platform-level security, such as Windows ACLs, is still required for system-level resources. Many of the most common application-level authorization scenarios use roles to categorize user groups that share the same permissions within an application.
The various licensing options available for ASP.net application developers and gatekeeper will be discussed further in the "Security model for ASP. NET Applications" chapter.
Secure communications
Examples of many applications that pass confidential data confidential data between application tiers, from the database server to the browser, or from the browser to the database server include details of bank accounts, credit card numbers, payroll data, and so on. In addition, when an application is traversing the network, the logon credentials must be protected.
Secure Communication provides the following two features:
•
Privacy. The concept of privacy is associated with keeping data private and confidential and cannot be viewed by eavesdroppers who are equipped with network monitoring software. Privacy is usually provided by the encryption mechanism.
•
Integrity. The secure communication channel also protects the data from being accidentally or intentionally (maliciously) modified when transmitted. Integrity is usually provided using an information authentication code (message authentication Code,mac).
At the same time, it is important to use secure communications inside and outside the firewall, as many harmful information exposure and security backdoor will appear inside the corporate network.
Secure communications and various applicable methods will be discussed further in the "Communications Security" chapter.
Back to the top of the page
Cooperation with the technology
asp.net Web applications can be developed using a variety of different technologies and products. A variety of authentication, authorization, and secure communication methods are required at multiple levels of the application to ensure deep security policy protection.
Figure 1 summarizes the various technologies and the basic authentication and authorization methods provided by each technology.
Figure 1. Security for. NET Web Applications
Back to the top of the page
Design principles
A number of important principles apply to the Guidance notes provided in subsequent chapters. You should learn these principles and apply them in your own application design:
•
The principle of least privilege. The process of running scripts or executing code should be run with the least privileged account possible, thereby limiting the possible damage when the process is compromised. If a malicious user manages to inject code into a server process, the permissions granted to the process will largely determine the type of action that the user can perform. Code that requires more trust (and higher permissions) should be isolated in separate processes.
The ASP.net team has consciously decided to run the ASP.net account with the least privilege (using the ASPNET account), which was implemented in the original version of the. NET Framework. However, in a beta version of the. NET framework, ASP.net runs as system and is inherently a less secure setting.
•
Use defense in depth. Set up checkpoints in each layer of the application and in each subsystem. Checkpoints are gatekeeper, ensuring that only authenticated and authorized users have access to the next downstream layer.
•
Do not trust user input. The application should thoroughly validate all user input and then perform actions based on user input. Validation may include filtering special characters. This preventative action protects the application against accidental use by users and in cases where someone deliberately attacks by injecting malicious commands into the system. Common examples include SQL injection attacks, script injection, and buffer overflows.
•
Use the default security settings. Developers tend to use less secure settings just to make the application run. If the functionality required by your application allows you to reduce default security settings or change these default security settings, test the consequences of the changes before you change them and understand the potential pitfalls.
•
Do not hide to protect security. Attempts to use confusing variable names to hide confidential information or store them in infrequently used file locations do not provide security. In the "Hide and seek" game, it is best to use platform functionality or use proven technology to protect your data.
•
Check at the gateway. You do not have to always pass the user's security context to the back end for authorization checking. Typically, this approach is not the best choice in a distributed system. Checking the client at the gate means granting user rights at the first authentication point (for example, within the Web application on the Web server) and determining which resources and operations are allowed to be accessed by the user, which may be provided by the downstream service.
If you design a reliable authentication and authorization policy at the gateway, you do not have to delegate the security context of the original caller all the way to the application data tier.
•
Assume that the external system is an insecure system. If the external system does not belong to you, do not assume that someone is safe for you.
•
Reduce the surface area. Avoid exposing information that you do not need to expose. If this information is exposed, it may cause further vulnerabilities. At the same time, the way to handle errors must be appropriate. When you return an error message to an end user, do not expose any information that you do not need to expose.
•
Displays the error message in a safe manner. If the application fails, be sure to protect the confidential data. Also, do not provide overly detailed data in the error message, i.e. do not provide any details that will help an attacker discover an application vulnerability. Detailed error messages should be written to the Windows event log.
•
Don't forget that your security program is constrained by the weakest link. When considering security, you should take into account the security of all tiers of the application.
•
Disables content that is not used. You can remove some potential attack points by disabling the modules and components that your application does not need. For example, if your application does not use output caching, you should disable the ASP.net output caching module. In this way, the application will not be compromised even if a security vulnerability is found in the module later.
Back to the top of the page
Summary
This chapter provides some basic information that you can prepare to read the rest of this guide by understanding this information. Since the core terms and principles described in this chapter will be widely used and referenced in the following chapters, you must be familiar with these concepts and principles.