. NET Programming Security Considerations

What's safe?

We cannot guarantee the absolute security of a system and it is impossible to achieve 100% security. The definition of security is subject to a lot of limitations, first let's take a look at an example.

We've all used ATM machines in the bank, and if someone picks up our card and wants to steal our money, then he only has to guess our password. If the length of the password is only one digit, then the first time the pick-up person guessed the probability is 1/10, he just 10 times can steal our money (assuming unlimited number of guesses), then the system is very poor security, if the password is 2, then the password is 100 possible, then the first time the pick-up person is the probability of 1/ 100, the second time is 1/99, the third time 1/98 ... the system's safety line is also very poor.

If the password attempt is limited to 3 times, if the password is 2 digits, then the probability of the password being guessed is greatly reduced:
The first chance to guess is 1/100.
The probability of a second guess (not the first) is (99/100) * (1/99) =0.01
The odds of a third guess (99/100) * (98/99) * (1/98) =0.01
The odds of guessing within three times are: 0.01+1.01+0.01=0.03

So, when we limit the number of attempts, the system is more secure than before, but the system is not very safe, can only say a little better than before, but the risk is still very large.

In order to make the system more secure, it is necessary to reduce the possible line of the system's password to be guessed, we can start from two aspects:

1. Reduce the number of password attempts, such as the user can only enter the password once;

      2. Increase the number of digits of the password, such as 6 bits. The probability of the password being guessed is even smaller, the risk is much smaller, and the system's safety line is improved. Therefore, we often say that security is not safe, is only a relative concept. Said so much, is to say a little: do not put the security look dead, security is not safe to see our environment.
 
        before we talk about the later topic, let's share some terms:
         vulnerability is a feature of the system that may make an application unsafe to operate as we expect. Generally indicates a bad feature of the system. The
        threat refers to the possibility of using the wrong human nature to break the system security.
        Utilization is the way to take advantage of fragile rows.
        The bottom line is that vulnerable lines lead to threats, and exploits threaten, in short, attacks.
 
        two security issues in Web Apps

First, let's look at the attack on the web. There are many types of attacks, some of which can be prevented with ASP. But other attacks can be disruptive, such as attacking the server directly. Here's a look at a typical example.
As we have said before, an attack is the use of the fragility of a system to achieve a certain threat. The results of the attack are also many, such as:
Unauthorized access-users gain more privileges, allowing applications to be used in other ways, if the administrator of the site gets the password and spreads political rhetoric.
Code execution-running malicious code on the target system, but also leads to other threats, such as Trojans.
Denial of service--legitimate users are forbidden to access the application
Theft of information--confidential information is stolen
Destruction of information-information has been modified. For example, sites have been altered to release offensive messages and political statements.

Let's look at some common vulnerabilities, the use of them, and the threats that arise.

Buffer overflow
This is a long-standing problem, and it is by far the most commonly exploited vulnerability of web applications.
The vulnerability of buffer overflow exists when the external input of an application is inserted into memory without being checked. If the length of the insertion exceeds the length of the allocated space in memory, the input overflows, which may occupy other places in memory or even run malicious code.

The main use of buffer overflow is to write additional data to the memory buffer in other places, which often lead to program crashes, because of memory corruption, this is the denial of the server attack, if the additional data design is very clever, additional data can also override the function return address, Then the program is executed according to the attacker's will, the virus, the Trojan is like this.

Of course, in C + +, this is a common problem because C + + can manipulate memory addresses directly and perform very low-level operations. But in. Is there a problem in net?
Because. NET is based on managed code, that is, the code for. NET is not directly manipulating memory, but is separated by a layer of CLR. The execution of managed code depends on the CLR as a boundary check, so any vulnerability in the CLR will be transformed into the fragility of the application. If a master knows the problem with the CLR, then the managed code also goes wrong.

Script injection and cross-site scripting attacks

At any time we have to have this mentality: the user is malicious. So we can not trust the user any input, when the user input must be tested. If the user's input is not properly handled, the vulnerability of script injection may be introduced into the program. This vulnerability allows users to inject their own amount of script into the data, such as in the user message, the user inserted "<script>alert (' Error ') </script>", then our Message page is the pop-up hint.
A cross-site script attack typically manifests itself as a script with a client in the URL parameter. These scripts are used to steal user's cookie information, etc.
We are here simply to say, some of the following articles will be specifically discussed, as well as solutions.

SQL injection
Believe this problem, we are more or less aware of some, mainly malicious users in our program's database execution of well-designed SQL statements. And the threat is large, set to get the permissions of the administrator of the server.

Distributed denial of service

Also known as DDoS (Disrtibute denial of Service). A DDoS attack is primarily a system that is attacked with a large number of computers. A lot of computers can be combined to send a lot of bogus requests, so that the system being attacked is overloaded, and cannot provide services to other users.
A deliberate tool must acquire enough machines to launch a DDoS. Malicious users designed to inject trojans and viruses into someone's computer, gain control of the machine, and "borrow" someone else's computer to send an attack. A controlled computer is called a "zombie."
DDoS attacks typically attack servers, and the way they are attacked is impossible, and many protection software and firewalls do not differentiate between correct requests and false requests.

People's problems
Sometimes, the vulnerability of being exploited is not a technical vulnerability, but a human vulnerability. If the user is not aware of security, it is easy to be deceived and open the system for the attacker. Many ways, such as using email to deceive users, to persuade users to execute some programs, there are worms ...

Brute Force attack
If you do not take certain measures to prevent users from endlessly trying to connect to the application, then we are vulnerable to countless guessing password passwords attack, that is brute force attack.
The main way to attack is to design a program that uses it to send a lot of requests to the target application to test different password passwords.

One thing to note: When considering security issues, we often compare programs as a castle, build walls around the castle, and strictly interrogate each channel. Protecting web programs is similar to this, but if so, we have nothing to do with users who have already entered the castle.

who will be responsible for the safety of the three

Many times the security problem is not only the programmer's responsibility, but in the system design time to start to consider the problem, and the security of the system is also a lot of people responsible for, such as:
The programmer should ensure that the program structure is safe.
Network administrator to ensure that the network and the server is secure
Programmers want to ensure that code does not introduce vulnerability
Database administrator ensures that the database server is not vulnerable
Users are also not to be deceived

Of course, there are many other tasks to be done to achieve security.

We're all developers, and here's a look at the issues that our developers can't solve:
Internet
Asp. NET program to be dependent on the network, if the network connection is interrupted, we have no way.

Web server and database server
If the server itself is not secure, then our code is not good to write in vain.

Client
We can finally control the client, and many malicious users can even bypass our client's JavaScript validation, to remember that the user is malicious.

We can solve the problem:
Put the safety in the first place.
It is important and difficult to build and maintain a system with a certain level of security. Previously, security issues were often thought of as external issues that were not considered in the program type.
Customers and managers will never agree to spend money on a feature unless they can see obvious benefits. As programmers, it is our responsibility to educate the rest of the company, to make them understand the importance of security, and not just to downplay the security issues as before, but to introduce them as core functions. The security function is always the core function of the system.

Achieve robust security features
To achieve the purpose of system security, as an ASP. NET developer, we have to add functionality in the program type. Safe systems are rigorously tested and reviewed. The question behind us will tell you more about the security architecture of ASP.

Avoid adding new vulnerabilities
New vulnerabilities may be introduced when code is added to a program. For the newly added code, a rigorous review is made to ensure that no security breaches are created.
Most of the time we have implemented the function first, and then we have to consider the security problem and do some maintenance. This is dangerous, so we consider the issue of safety at the start of the project.
There is also a need to remember to delete the obvious loopholes in our program. We may have used test code when developing debugging, such as:
public bool ValidateUser (string userName)
{
Testcode
if (username= "app")
return true;
//....
}
We can add//testcode to the code (see above) and then find all "Testcode" after the project is complete and delete it.

We also educate users, they have a certain understanding of security issues, we have to verify the user's input, or the sentence: All users are malicious.

Iv. give some advice
It's not safe.
In the field of computer security, "the only secure system is a system that is locked in a security cabinet without powering on". We must admit that it is impossible for the system to determine security, and if the attackers are capable and patient enough, they will eventually find a way to invade the system.
Since it is impossible to be absolutely safe, what shall we do? We can make it harder for unauthorized access to the system as much as possible. This would be like increasing the height of the fence, and the attacker would have to pay more effort to gain access. And a lot of attackers are speculative-looking for easy-to-attack objects.

It's not safe to hide.
We often hide some private files in the secret directory of our web site and then just tell the people we trust. However, hiding does not guarantee real security. Examples are many, such as companies that use hidden connections on Web pages to provide access to a "private" directory. These connections may be hidden in a corner with a transparent graphic, not visible to the Web page, but for web search engines, the hidden links are no different from other links.

So, hiding is not necessarily safe. And now often use encryption algorithm, the reason is because the algorithm after rigorous review and crack test, in a certain time the algorithm is safe, if there is an algorithm, the crack takes decades or even longer, in the existing stage, we can also be said to be safe.

The security of the application is determined by its weakest link
We all know the bucket template principle: How much water bucket to fill the shortest block of the template to decide. The same is true for security issues. Because malicious users want to enter the system, will try a lot of ways very way, once the program's weakest Link is found, the whole system can imagine.
It is recommended that when the system is developed and completed, the structure diagram of the system is built, and then the database server is marked from the client to the terminal, then the connection is analyzed and the possible problems are improved.

Safety issues throughout project development
From project design through to later deployment, security has to be considered. Do not add security until the end.

Excessive security will be detrimental to the development of the project
Sometimes, excessive emphasis on security is not a good thing. If the system is very demanding, the system requires the user's password to be 12 characters, and 2 non-numeric characters, as well as uppercase and lowercase letters. Users will probably not remember the password, even if they write the password directly on the paper on the computer, then nothing safe. So the security of the scheme to compromise, and users to discuss more.

Security is more than just a matter of technology.
As mentioned earlier, in the security aspects of what we developers can do, a lot of times, the user is a security weak link, so also to strengthen user safety education.

. NET Programming Security Considerations