ASP. NET security issues-creating secure Web Applications

To clarify a question, we must have a premise and some passing words. Just like talking about OO, we can understand the object-oriented language, and some object-oriented features; those who understand the design pattern will immediately know what they mean when they hear "Observer.

 

First, let's see what security is?

We often mention "implementing security" and "Creating a secure system ". Therefore, security is generally defined. For example, security means to ensure that the system can run in the way we want. Security means to prevent the system from running in the way we don't want it... there are many definitions, but I don't know if you have found that the security definition we understand is very narrow. What do you say? We generally think that security is like this: take certain measures (mainly programming code measures) to handle program running exceptions or prevent accidents. But the security issue is not just about code, so we need to consider more about security programming.

What is security

We cannot guarantee the absolute security of a system, and cannot achieve 100% security. Security definition is subject to many restrictions. Let's take a look at an example.
We all use bank ATM machines. If someone finds our card and wants to steal our money, he only has to guess our password. If the password is only one digit in length, the probability of the first guess is 1/10. he can steal our money as long as ten times (assuming he can guess for unlimited times ), the security of the system is very poor. If the password is two digits, the password may be 100, so the first chance is 1/100, and the second is 1/99, third 1/98... the security of the system is also poor.

If the password is limited to three attempts, and the password is two digits, the chance of being guessed is greatly reduced:
The probability of the first guess is 1/100.
The probability of a second guess (not in progress for the first time) is (99/100) * (1/99) = 0.01
The probability of the third guess (the first two do not) is (99/100) * (98/99) * (1/98) = 0.01
The probability of being guessed within three times is: 0.01 + 1.01 + 0.01 = 0.03

Therefore, when we limit the number of attempts, the system is more secure than before, but the system is not very secure. It can only be said that it is a little better than before, however, the risk is still high.

To make the system more secure, we need to reduce the possibility of the system password being guessed. We can start from two aspects:

1. Reduce the number of password attempts. For example, you can only enter the password once;

2. Increase the number of passwords, such as 6 digits. In this way, the chance of the password being guessed is even lower, and the risk is much lower, so the security of the system increases. Therefore, we often say that security is not safe, and it is just a relative concept. If you say so much, you just need to say: do not put security into consideration. Security or insecurity depends on our environment.
 
Before talking about the following topics, let's share some terms:
It is a feature of the system. It may make the application system run in an insecure way as we expected. It generally indicates the characteristics of the system that are not good.
This is the possibility of using the wrong human nature to break the ring system security.
It is the method of using vulnerable rows.

First, let's look at the Web attacks. There are many types of attacks, some of which can be prevented using ASP. NET code, but other attacks can still cause damages, such as direct attacks on servers. The following is a typical example.
As we have said before, attacks use system vulnerabilities to pose certain threats. There are also many, such:
-- The user obtains more permissions, so that the application can be used in other ways. If the user obtains the password of the website administrator, political comments are spread.
-- Run malicious code on the target system and cause other threats, such as Trojans.
-- Valid users are prohibited from accessing the application.
-- Confidential information is stolen
-- Information is modified. For example, the website is altered to publish aggressive messages and political comments.

Next, let's take a look at some common vulnerabilities, their utilization, and the threats they cause.

This problem has been around for a long time and has become the most common vulnerability in Web applications.
When the external input of the application is inserted into the memory without being checked, There is a buffer overflow vulnerability. If the inserted length exceeds the size of the space allocated in the memory, the input overflows and may occupy other places in the memory or even run malicious code.

The main use of buffer overflow is to write the additional data to other places in the buffer zone in the memory, which often leads to program crash because the memory is damaged, which is also a method to reject server attacks, if the appended data is cleverly designed, the appended data can also be rewritten to the return address of the function, then the program will execute according to the attacker's wishes, such as viruses and Trojans.

Of course, in c ++, this problem is very common, because C ++ can directly operate on the memory address to perform very underlying operations. But does. NET also have this problem?
Because. net is based on managed code, that is to say, the. net Code does not directly operate on the memory, but is separated by a layer of CLR. The execution of managed code depends on CLR as the boundary check, so any vulnerability in CLR will change to application vulnerability. If a master knows about the CLR problem, there is also a problem with the managed code.
 

 
At any time, we need this mentality: users are malicious. Therefore, we cannot trust any user input, so we must check the input. If user input is not properly processed, the vulnerability of script injection may be introduced into the program. This vulnerability allows users to inject their own scripts into data. For example, in a user message, the user inserts "<script> alert ('error') </script> ", A prompt is displayed on our message page.
A cross-site scripting attack is typically a script with a client in the URL parameter. These scripts are used to steal users' cookie information,
Let's just briefly talk about the following articles and solutions.

I believe this problem is more or less known to all, mainly because malicious users execute well-designed SQL statements in the database of our program. In addition, this vulnerability is highly risky. You can obtain the administrator privilege of the server.
 

 
Also known as DDOS (disrtiancdenial Of Service ). DDOS attacks are mainly used to attack a system with a large number of computers. Many computers can send a lot of fake requests together, so that the attacked system is overloaded and cannot provide services to other users.
To launch DDOS attacks, deliberate tool providers must acquire enough machines. Malicious users are designed to inject Trojans and viruses into others' computers to gain control of the machines and send attacks to others' computers. A controlled computer is called a zombie ".
DDOS attacks generally attack servers, and the attack methods are hard to prevent. Many protection software and firewalls cannot distinguish between correct requests and false requests.
 

Sometimes, the vulnerability being exploited is not a technical vulnerability, but a human vulnerability. If users do not have security awareness, they are easy to get cheated and open the system for attackers. There are many ways, such as using Email to spoof users and entice users to execute some programs, as well as worms...
 

If we do not take certain measures to prevent users from constantly trying to connect to the application, we will be vulnerable to attacks with countless password guesses, that is, brute force attacks.
The main attack method is to design a program that sends many requests to the target application to test different passwords.

 
One thing to note: when considering security issues, we often regard programs as a castle, build walls around the castle, and strictly check the channels. The protection of Web programs is similar. However, if so, we have no plans for users who have already entered the castle.
 

 
In many cases, security is not only a programmer's responsibility, but also an issue that begins to be considered during system design. In addition, many people are responsible for system security, such:
Ensure that the program structure is safe
Ensure that the network and server are secure.
Make sure the Code does not introduce vulnerabilities.
Make sure that the database server is not vulnerable
Do not be deceived.

Of course, there are many other tasks that need to be done well to achieve security.
 
We are all developers.
ASP. NET program running depends on the network. If the network connection is interrupted, there is no way.

If the server itself is not secure, it will be futile to write our code.

After all, we can control the client, and many malicious users can even bypass javascript verification on our client. Remember that users are malicious.

Building and maintaining a system with a certain security level is an important and difficult task. In the past, security issues were often considered external problems, but they were not considered in programs.
Customers and managers will never agree to spend money on a feature unless they can see obvious benefits. As programmers, we have the responsibility to educate other people in the company so that they can understand the importance of security. We should not just describe the security issue, but introduce it into the system as the core function. Security is always the core function of the system.
 
To achieve the purpose of system security, as an ASP. NET developer, we need to add features in programs. Secure systems are strictly tested and reviewed. The following questions will detail the security architecture of ASP. NET.
 
New vulnerabilities may be introduced when code is added to programs. The newly added code should be strictly reviewed to prevent security vulnerabilities.
We usually implement functions first, and then consider security issues and perform some maintenance. This is dangerous, so we should consider security issues at the beginning of the project.
Remember to delete the obvious vulnerabilities in our program. We may have used the test code during development and debugging, for example:
Public bool ValidateUser (string userName)
{
// TestCode
If (userName = "app ")
Return true;
//....
}
We can add // testCode in the Code (see the above). After the project is complete, find all "testCode" and delete it.

In addition, we also educate users about security issues. Do we verify user input or say that all users are malicious.
 


There is a saying in the field of computer security, "the only secure system is locked in the security cabinet without power-on ". We must acknowledge that the system cannot determine security. If attackers have sufficient capabilities and patience, they will eventually find ways to intrude into the system.
What should we do if it cannot be absolutely secure? We can try our best to make it more difficult for unauthorized access systems. This is like increasing the height of the guardrail. If attackers want to gain access permissions, they have to make more efforts. In addition, many attackers are speculative-only looking for targets that are easy to attack.
 

We often hide some private files in the secret directory of the Web site, and then only tell people we trust. However, hiding cannot ensure real security. There are many examples. For example, the company uses hidden connections on the web page to provide access to the "private" directory. These connections may be hidden in a certain corner using a transparent image, which is invisible to people on the web page. However, for the network search engine, the hidden links are no different from other links.

Therefore, hiding is not necessarily safe. In addition, encryption algorithms are often used because the algorithms have undergone rigorous review and cracking tests. The algorithms are secure for a certain period of time. If there is an algorithm, cracking takes decades or even longer. In the current stage, we can also say that it is safe to use.
 
Everyone knows the principle of the bucket template: the amount of water in the bucket is determined by the shortest template. Security issues are the same. Because malicious users want to enter the system, they will try many ways. Once the weakest link of the program is found, the whole system can be imagined.
We recommend that you create a system structure chart when developing and completing the system, mark all the links from the client to the database server of the terminal, analyze the connection between them, and think about possible problems, improvement.
 
Security should be taken into account from the design of the project to the later deployment. Do not add security measures until the end.
 
Sometimes, excessive emphasis on security is not a good thing. If the system security is demanding, for example, the system requires that the user's password must be 12 characters long and contain 2 Non-numeric characters and uppercase and lowercase letters. Users may not be able to remember the password. Even if they directly write the password on the computer, there will be no security. Therefore, the security solution should be compromised and discussed with users.
 

As we have mentioned earlier, in terms of security, we can do things that developers can do. In many cases, users are weak in security, so we need to strengthen user security education.