There are two types of Software defects that cause security problems: Deployment vulnerabilities and design defects. Most of the current focus in the software security market is on discovering and fixing vulnerabilities, mainly because the automated code review tool makes the process very simple. In fact, defects in software design and architecture also account for a large proportion, which accounts for 50% of all security problems.
In this article, we will explore the differences between vulnerabilities and defects. More importantly, we will introduce the architecture risk analysis (ARA) Program, which has proved to be able to detect and fix vulnerabilities well.
So what are the differences between vulnerabilities and defects? Maybe we can draw conclusions from some examples.
Vulnerabilities
Vulnerabilities exist in software code (source code or binary code. One of the most classic vulnerabilities is the buffer overflow vulnerability, which fundamentally involves misuse of some string processing functions in C. The most notorious function is gets (), which is a system call that retrieves input from the user until the user decides to click "reply. We think of a fixed-size buffer zone as an empty water cup, and then imagine that you have set a method to fetch water from the cup to avoid full cups (attackers are constantly pouring water "). If too much water is poured into the cup and the water overflows, It is spilled on the table. When the buffer in C overflows, too many input will overwrite the heap, or even overwrite the stack, which destroys the program stack, causes the program to crash or causes the program to execute other commands for attacks. Simple vulnerabilities and terrible consequences. In the face of the gets () problem, it is particularly easy to find the vulnerability in the source code.
There are hundreds of system calls in C. If improperly used, they may cause security vulnerabilities, including problems from string processing to integer overflow and integer overflow. Of course, there are as many errors as in Java and other languages. In addition, common vulnerabilities and database-related vulnerabilities (such as SQL Injection Vulnerabilities) also exist in Web applications (such as cross-site scripting or cross-site Request Forgery ).
Faced with so many possible vulnerabilities, we need to deploy and use some tools to find them. There are many commercial Source code review tools on the market, such as HP's Fortify, IBM's AppScan Source, Coverity's Quality Advisor, and Klocwork's Clocwork Insight. The latest breakthrough in source code review is to directly integrate vulnerabilities to find the integrated development environment (IDE) of every developer, so that we can discover the vulnerabilities as soon as possible. For example, this is the principle of SecureAssist in cigbench.
Defects
In addition to vulnerabilities, we also see defects. Defects exist in the software architecture and design. Here is an example of a very simple defect: Forgetting to verify the user. This type of error cannot be found during code review, but this is an extremely serious problem. Is your process running as root? It is best to determine who is using it!
Other examples of defects include the "Intermediate attacker" problem, which allows attackers to tamper with or eavesdrop between components, network layers, machines, or networks. In addition, there are also "replay attacks" related to bad protocols.
To better describe the defects, we listed some common Java-related defects here: Incorrect password system, partition issues in design, privileged block protection faults (DoPrivilege ()) catastrophic security faults (vulnerabilities), classified security obfuscation errors, insecure auditing, damaged or illogical Access Control (RBAC at the network layer), method coverage issues (subclass issues) and give too much trust (client) to components that should not be trusted ). (For more information about these issues, see McGraw's protecting Java ).
Defects are as common as vulnerabilities. In fact, most studies show that vulnerabilities and defects each account for 50%. Of course, what we discuss in this article is the unity of the two. There are also some tricky situations that may be categorized as vulnerabilities and defects at the same time, depending on what you think about it. However, in general, learning to distinguish between vulnerabilities and defects makes sense to you.