Asp. NET application architecture and security planning

Asp.net| Security | program | Planning through the study of the previous article, "Planning basic asp.net Applications", with the basic purpose and the list of user scenarios developed for the solution, you need to start planning the overall architecture. The primary goal is to identify the logical and physical aspects of the application, that is, how to split the application into various useful parts. The security aspect is also added to this section. Security is the problem you need to consider at the start of planning, not the "last additions" in the development cycle. We will discuss this issue in detail later in this section.

Logical architecture

Logically, you need to plan your solution to identify "boundaries" between data storage, data access, business rules, user interfaces, and so on. Typically, a web developer chooses a two-phase model and uses Web forms to store all of the code used to access an existing data storage system, such as Microsoft SQL Server. A more efficient approach is to create a middle-tier component library that is located between the Web forms user interface and the SQL Server data storage System. This three-tier approach (Web forms, components, databases) is typically required by most applications. However, in some cases, you may need a different layer to handle the data transferred between servers. This transport layer can be implemented using platform-independent protocols such as XML-SOAP. However, if you use Microsoft. NET technology from beginning to end, you can do this using the. NET remote protocol's binary sedan, which is much faster than using XML-SOAP.

For our example, we will define three logical boundaries: the user interface (Web form), the middle tier (a. NET component assembly), and the data tier (SQL Server database). Figure 1 shows such as pseudo Xing Chrysanthemum Hotel barren 谌荨?



Figure 1: Three layer diagram

Now we have a simple logical model. How does it work? It helps us to consider the boundaries between each logical group. Each logical layer should be as independent as possible with the other layers. Ideally, changes in the layer should have a minimal effect on the whole. For example, if you change the data store from SQL Server to an XML data file, the only layer that is affected should be the middle tier layer. The user interface should not consider changes at all. This will allow you to think about how to implement the actual coding of the solution to achieve this principle.

In addition, the logic layer helps us consider security issues. There are potential security vulnerabilities in the boundaries between each layer. Also, each layer may have its own specific security measures (SQL Server permissions,. NET run-time permissions, asp.net security, and so on). Again, we will discuss this issue in detail later in this section.

Physical architecture

After the logical layer is identified, it is also important to consider the physical layer. For example, you can implement this application on a single actual computer that has SQL Server, Internet Information Server, asp.net, and. NET runtime installed at the same time. This will be a physical layer. But a more reliable and scalable approach is to deploy a Web form on a cluster of three Web servers, deploy the. NET component assembly on two application servers, and deploy the database on two recovery-mode SQL Server. The resulting physical architecture includes seven Windows servers in three primary groups: Web clusters, component clusters, and database clusters. If you understand that different logical parts of your system can be located on different computers, you may implement different code.

For our example, we employ an effective and powerful two-tier model: The WEB server managed user interface and components, and the database server hosts the SQL Server data store. If traffic is very large, this model gives us the flexibility to add more servers to the cluster and keep it simple enough to handle. The following image shows the mapping relationship between this physical architecture and the logical architecture defined earlier.



Figure 2: Mapping between a physical architecture and a three-tier architecture

As you can see, the logical architecture and physical architecture do not have to be the same. In the planning phase there is one more element to consider: security.

Security Planning

Microsoft has a mnemonics on the subject of security and software: "Secure by, security by default, and secure by deployment (design security, default security, and Deployment safety)". That is, design in security, expect the system to be safe by default, and create solutions that can be deployed successfully in a secure environment. Security is always important. Since more and more software is going to "survive" on the public Internet, writing secure software is even more critical. Fortunately for us, the. NET runtime and the Windows operating system provide a wide range of security options and features that we can easily include in our applications. Instead of focusing too much on identifying and eliminating the details of vulnerabilities in online solutions, we can point to some of the most common vulnerabilities and point out how our application planning is handled.


Buffer overflow

This may be the most common security vulnerability in a compiled application. Because we will use the. NET runtime, which is designed to run safely in memory, it is unlikely that a buffer overflow can occur. In addition, we encode the solution using Microsoft Visual Basic®.net, and Microsoft Visual basic®.net is not as vulnerable to a buffer overflow problem as C or C + +. However, even if we intend to create components in C + +, we can also use the special features of the compiler, GS conversion, to protect us from most buffer overflow attacks.

Database attacks

Another common security vulnerability could allow a malicious user to gain access to the raw data stored in the database. To prevent hackers from gaining control over data, we use only SQL Server stored procedures instead of inline queries. This can greatly reduce attacks that attempt to insert additional SQL commands into the input stream. We also use input validation in multiple locations in the program to ensure that all input contains only valid characters.

Cross-site scripting attacks

Another common attack on Web applications involves users adding client script to the input stream, which will perform additional conversations and trick users into sending personal data to their own web site. To solve this problem, we use a new feature of ASP.net 1.1 to filter out all input of this malicious code and prevent it from being placed into the system. The display screen also contains additional code that automatically disables any script or displays the markup that may be inserted into the data store.

At this point, we have obtained the logical model and physical model of the application, as well as the list of security features that the implementation solution contains. With these and the target statements and user scenarios, we can start the last part of the "pre-coding" adventure.