Security rules in test Space

 

Security rules in test Space

The test space is a basic knowledge of software. The following describes some security guidelines for the test space. These guidelines can be used in software security design, software interface design, and security testing.

1 Security Principle 1: The test space must be as small as possible and easy to construct

All security defects of software come from the test space. A software with security requirements must make the test space as small as possible to meet the requirements. If the test space is too large, the amount of untested space will increase, leaving a lot of room for attacks. For example, if the length of a string entered in an interface cannot exceed 16 bytes, you can limit the length of the input string to 16 bytes. In this way, the size of the test space is limited. Otherwise, various exceptions that exceed 16 bytes are tested. After the length of 16 bytes is exceeded, the buffer overflow usually occurs.ProgramIf a buffer overflow occurs, other unauthorized users can use this buffer overflow vulnerability to log in.

The test space is not light enough, and it must be easily constructed. The test cost is small and the coverage rate is high. If the construction is difficult, it is difficult to cover all the test space during testing, leaving room for attackers. Therefore, many testing data that is difficult to construct during the black box test must be constructed during the white box test for testing.

2 Security Guidelines 2: establish the strictest conversion rules between the test space and the design space

Even if the design space has been minimized to meet the requirements, if the converted space is much larger than the design space during the transition from the test space to the design space, in this case, attackers can still use legal means to launch attacks in an extra space.

There is a path environment variable spoofing problem in Unix systems. Common users can use programs that call or call external commands to become superusers. The main reason is that the program depends on the path environment variable when executing external commands. After attackers change the path environment variable, they will execute the program with the same name in the specified directory. This lack of strict validation of the executed external program provides an opportunity for attackers.

Therefore, it is necessary to establish the strictest conversion rules. Once the conversion rules are not strict, the abnormal space may become a hotbed of attacks.

3. Security Criterion 3: design space conversion rule validation at the external input layer

All attack data must pass the external input layer to enter the program. Therefore, the data at the external input layer must be verified by the design space conversion rules so that the data meeting the design space conditions can pass, reject data in the abnormal space. This will greatly reduce the chance of attacks in the abnormal space. For example, a program needs to accept a 0 ~ If the input value is an integer of 100, check whether the input data is between 0 and on the input interface ~ If the value is not within the range of 100, an error is prompted.

In the conversion process, you also need to ensure the type security. Otherwise, there are defects in the conversion process, which will also provide an opportunity for attackers.

4 Security Principle 4: The intersection of abnormal spaces at each layer of the test space should be as small as possible

The intersection of abnormal spaces at each layer of the test space should be as small as possible. In other words, the intersection of the external input layer, interface layer, and Implementation Layer in the test space must be as close as possible to the design space. As shown in:

Figure 10-1-1 intersection of test space Layers

Why do we need to ensure that the intersection of abnormal spaces at each layer is as small as possible? Because there may be omissions in the conversion process from each layer of space to the design space, and omission occurs in their intersection, the intersection will become a breakthrough for attackers. If there is little difference between their intersection and the design space, the exception space left for attackers to easily launch attacks will also become small.

Abnormal spaces in non-overlapping areas may also be attacked, because the test space is converted to the design space.CodeThis vulnerability may exist, making it possible to initiate an attack in a non-consortium.

5 Security Guidelines 5: The design space must be as small as possible to meet the requirements

If the design space is too large, there will be more room for attackers, because attackers can construct attack methods through legal channels. Such attacks will be hard to prevent.

The famous DoS attack is an example in this regard. The reason why DoS attacks can be carried out is, one of the reasons is that there is no fair traffic rule on the Internet and the server does not reject a large number of connections in a short period of time. Specifically, the design space for data transmission over the network is not minimized.

The premise of reducing the design space is to meet the requirements. If the design space is too small to meet the requirements, it will also cause serious problems, for example, the millennium worm problem is that the design space is too small to meet the requirements. The millennium worm problem has not become a worldwide problem in the 20th century. It has become one of the most important events in computer history, because it lacks two bytes of design space.

If the design space is too small, it may cause overflow because it cannot meet the requirements, for example, memory out-of-bounds, numeric overflow, and so on. Therefore, designing a reasonable design space is of great help to improve the security of the software.

6. Security Rules 6: The test space at each layer must be larger than the design space.

In the software, due to requirements or design defects, sometimes the local test space is smaller than the corresponding design space: for example, a command line program, the user-entered commands and parameters can exceed 1024 bytes of valid strings, but in the implementation process, the buffer size used by programs that accept user input is 4096 bytes, however, in the specific processing function of the command, it is copied to a character array of only 1024 bytes, which causes the test space of the internal implementation layer to be smaller than the design space.

If the test space is smaller than the design space, there may be overflow errors or computing errors in the program, or the requirements may not be met. As in the preceding example, if the source string length is not verified when the command is copied to a specific handler, a buffer overflow error occurs. If the source string length is verified, the function cannot be implemented, the requirements cannot be met.

7. Security Guidelines 7: high coverage of test Space

The defect space cannot be known when it is not fully tested. This issue will be carefully discussed in chapter 3rd test case design method. However, the software cannot be fully tested due to the huge test space. How can we achieve a high test coverage rate for the selected test cases? Here, let's take a look at related topics.

First, in the analyzed known defect space, the test case should reach 100% of the known defect Space coverage rate. Then, add new use cases: for the boundary condition, consider all kinds of boundaries. For the equivalence class, you can randomly select some data in each equivalence class as the test data; for classification reasoning, the finer the classification, the better.

After a new test case is added, the coverage rate is still 100% for the known defect space, but it is not improved for the entire defect space, the probability of overwriting the added test case is greatly increased, and the coverage of the entire test space is naturally increased. Of course, how many use cases need to be added depends on the degree of security requirements of the software and the economic benefits of the software. You cannot add use cases without limit so that the total cost of development and testing exceeds the benefits you can achieve.

Therefore, it is necessary to increase the coverage rate of the test space as much as possible to meet a certain economic cost to increase the security of the software.

8 Security Principle 8: handling of abnormal space should be as simple as possible

The handling of Abnormal Space in the software should be as simple as possible. If the data in the abnormal space has been determined, it should be processed in the simplest way. Otherwise, attackers may exploit the vulnerability to process abnormal data.

If it is a network server software, the network connection should be closed immediately after receiving abnormal data from the client. Do not give the client any response information as much as possible, and only respond once within the specified time. Otherwise, it is easy to be exploited for attacks. The famous Ping flood attack is caused by errors on the Internet and control packet protocols.

The above are some basic principles on software security. They are necessary but not adequate for software security. Meeting the above rules alone does not mean that the software is secure. As mentioned in chapter 1st, software testing is a process of finding test space, design space, and defect space, verifying whether the design space is correctly implemented, and verifying whether the Abnormal Space causes problems. It is very important to verify whether the design space is implemented. design space verification not only verifies data legitimacy, but also includes whether there are problems in the process. During the process of processing measurable data, software may still have many vulnerabilities, making it possible to be attacked.

This article is excerpted from "software testing practices" by Zhou weiming