First, change the perspective
Taking a user login function as an example, when the wrong user name is entered, the prompt information is "The user name does not exist"; when the user name is correct and the password is wrong, the prompt information becomes "password input error." For real It is very good for users and can effectively narrow the scope of error correction. But the security tester will jump out: "This prompt information needs to be changed! Sensitive information is exposed!" Because of the prompt information, malicious system users can infer which usernames already exist in the system, and then use these usernames to perform further tests. The brute force cracking of passwords reduces the scope of cracking. Therefore, although this information provides convenience for legitimate users, it also provides convenience for malicious system users. Often this convenience benefits malicious system users far more than legitimate users.
Second, change the object mocked in the test
To be able to see the software from a different perspective, we have to change the object we simulate. It's also an effective way to deliberately practice shifting perspectives.
When we do non-security testing, we usually imagine ourselves as a legitimate user, and then start to verify that the system can achieve the preset goals. For example, for an online mall, we will verify whether the system allows users to browse and purchase products, and we will also test some abnormal behaviors, such as when the number of purchased products is not a number but a string of meaningless letters, the purpose is to see Whether the system can respond more gracefully. The purpose of our testing is often to ensure that users can continue their purchases after misoperation, or to not cause serious damage to the system.
If we want to do security testing, we have to simulate another type of user of the system - malicious user. Their purpose is to find exploitable holes in the system. For example, in the same online mall, one of the goals of malicious users is to find a way to get the goods with less money, or even without paying. Therefore, if malicious users make "misoperations", they will not stop at "misoperations", but will see whether the system provides more clues for themselves through "misoperations".
So, we switch the object we simulate when testing, pulling the mind out of the point of view of a legitimate user and converting it into a malicious user. It takes a little time to deliberately practice.
Third, use dedicated testing tools
With a mind shift, we can add new test ideas. However, when doing specific security testing, we will find that it is not so easy to simulate the behavior of malicious users. After all, the front end of the system will give us a lot of barriers. And malicious users don't always get in through the front door of the system. At this time, it is very helpful to use some tools, such as OWASP Zap (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project), Burp (https://portswigger.net/burp/), etc. We can perform functional testing use cases on the system interface, use these tools to obtain http requests, tamper with them and send them to the backend server. With these practical and relatively easy-to-use tools, we can perform many operation scenarios of malicious users.
If you can do these three points, it is basically enough to start.
For example
Let's use the function of uploading pictures in the product evaluation by the buyers of the online store to explain how to practice this "three-axes". Assuming we've been on board from the very beginning of the project, we have roughly seven things to do:
Identify valuable data in the system;
Add malicious user requirements in the requirements analysis stage;
Design test cases for malicious user requirements;
Participate in the development of initiating malicious requirements;
Accept the implementation of malicious requirements in the development environment;
Security testing in a test environment;
Provide feedback to the team on security vulnerabilities discovered.
Don't worry, it's not 7 brand new things. It just adds security to every place a tester needs to be present.
1. Identify valuable data in the system
Many people think that performing tests is testing, and our security testing starts here.
After understanding the business, we need to consider what valuable data will be in the system. This is to prepare for the next step to add malicious user requirements. For an online store, valuable data can include product information, order information, user information, payments, and so on.
There is not much extra work for our testers in this link. After all, we also need to understand the business when we do non-security testing. Note, however, that the "image upload function" we're going to test is a function that involves valuable data. We need to be more vigilant.
2. Add malicious user requirements in the requirements stage
Malicious user requirements are used to record what malicious users want to achieve in the system. The difference from normal user requirements is that we are not trying to implement it, but using it to help us stay away from "inappropriate trust" in the users of the system. Usually we need to add one or more corresponding malicious user requirements for each legitimate user requirement.
For example, if our legitimate user requirements for the "image upload function" are:
As a buyer, I want to upload a picture as a buyer's show when I rate the product, so as to participate in the cashback marketing campaign.
Then the corresponding malicious user requirements can be:
As a malicious user, I want to sabotage the buyer's show cashback campaign in order to sabotage the marketplace's marketing activities.
"Sabotage the buyer's show cashback campaign" is a big goal. It can be subdivided into a series of small goals for the convenience of designing a use case. for example:
- Make users unable to upload pictures
- Make the page not display pictures correctly, etc.
With the backbone information of malicious user requirements, we can start the next step of designing security test cases.
3. Design test cases for "malicious user requirements"
Now what we need to do is try to limit ourselves to the point of view of "malicious users" to do brainstorming: "Is there any way to prevent buyers from uploading picture information?", "What if the page cannot correctly display buyer's show pictures? Do it?" Well, perhaps the most direct way is to power off the computer room where the server is located, disconnect the network, etc. These are some good ideas, albeit a bit difficult to implement. It's okay, record it. In addition to this, we can also have other test cases, such as:
- The disk space for storing pictures is full and new pictures cannot be accepted;
- Makes the process of uploading images too busy to accept new upload tasks;
- Uploading a particularly large image makes the user's client take a long time to download
- Upload malicious code disguised as a picture, further gain server permissions, delete all buyer show pictures, etc.
If you think of a new test case at this time, you can also record it, such as "I want to upload a picture of the buyer's show to get cash back even if I don't want to buy it".
Don't worry too much about the "crazy" or incomplete test cases at this stage, after all, we don't know much about the implementation of the system. We will refine the specific steps in the next link.
4. Participate in the development of evil story kickoff
Before developers start to develop legitimate user requirements, we need to communicate with business analysts and developers about the content of the requirements. In agile software development projects we call it story kickoff, or user story kickoff. When there is a corresponding malicious user demand, we must also add it to the scope of startup. The purpose is to communicate the test cases we brainstormed to all the roles. Prevention is better than detection.
5. Accept the implementation of malicious requirements in the development environment
100% prevention of software defects and vulnerabilities is unlikely, so this link exists for early feedback.
I once experienced a project that was almost online before I decided to do a security test. One of the problems detected was that the user session could not be properly expired. After some research, I found that the architecture of the system design needs to be For relatively large revisions, we can only make a temporary repair to let the system go online first, and then change the architecture of the system, rewrite this part of the function, and re-test. The price is very high. Therefore, whether it is a security test or a non-security test, the step of "accepting the implementation of malicious requirements in the development environment" is indispensable.
The second purpose of this link is to allow us to get support from the developers - the details of the specific implementation, to help us improve the specific test cases. For example, at this point in time, if we know from the developer that the background of the system does not authenticate the image uploader, we can add at least one test case: "A malicious user uploads an unrelated image as another user. and pictures". Sometimes the wrong picture is more lethal than no picture at all.
6. Conduct security testing in a test environment
It's finally time to run the tests. Maybe the test case we thought of before has been solved by the developer at this time. If so that would be great. However, the reality is not so beautiful. First, these use cases may only be successfully passed in the development environment, but in an ideal test environment, that is, a production-like environment, these use cases may not completely pass; second, there must be other places to explore. At this time, we can use tools such as OWASP Zap and Burp to assist us in executing the previous security test cases once, and at the same time, we can do exploratory tests on the security of the system.
7. Provide feedback to the team on discovered security vulnerabilities
When the measurements are almost the same, we can report the results of the security testing to the team and relevant stakeholders. The difference from non-security testing is that when we report security vulnerabilities, we must consider whether the combination of different vulnerabilities will increase the security risk of the system. For example: if there are two security loopholes, one is that the system does not have strong user account password rules, and the other is that the system does not limit the size of uploaded pictures, then a malicious user combines these two loopholes, and things will change. Much riskier than before. Then we have to recommend raising the priority of either of these two vulnerabilities.
Original address:
http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safety-test?utm_source=articles_about_Security&utm_medium=link&utm_campaign=Security