8.8. Defense Framework¶
8.8.1. Defense Depth¶
According to the depth, defense can be divided into physical layer, data layer, terminal layer, system layer, network layer, and application layer. There is a progressive and interdependent relationship between these layers of depth.
8.8.1.1. Physical Layer¶
The physical layer has fewer contacts in practical applications, but is still a very important location. If the physical layer is not properly designed, it is easy for attackers to bypass the upper layer defense through physical means.
8.8.1.2. Data Layer¶
The data is located at the lower level of the defense depth, and the target of the attack is often to obtain the data. Many defenses are also based on the data not being destroyed or stolen.
8.8.1.3. Termination Layer¶
Terminals include PCs, mobile phones, IoT, and other smart devices. Whether the terminals connected to the network are trustworthy is a problem that needs to be solved.
8.8.1.4. System layer¶
The operating system runs on the terminal, and there may be problems such as privilege escalation and unauthorized access.
8.8.1.5. Network layer¶
The network layer uses communication lines to connect multiple computers to each other and communicate according to agreed protocols. Attacks such as MITM and DDoS exist at the network layer.
8.8.1.6. Application Layer¶
The application layer is the top layer, which mainly involves various attacks on Web applications.
8.8.2. Access Control¶
Web applications need to restrict user access to the application’s data and functionality to prevent unauthorized access by users. The process of access control can be divided into three parts: authentication, session management and access control.
8.8.2.1. Authentication Mechanisms¶
The authentication mechanism is a basic part in the user access processing of an application, and the authentication is to determine the validity of the user. Most web applications use an authentication model where the user submits a username and password and the application checks its validity. In applications where security is important, such as banking, the basic authentication model often requires the addition of additional certificates and multi-level login processes, such as client certificates, hardware, etc.
8.8.2.2. Session Management¶
In order to implement effective access control, the application needs a way to identify and handle this series of requests from each of the different users. Most programs will create a unique token for each session to identify.
For attackers, the session management mechanism is highly dependent on the security of the token. In some cases, an attacker can masquerade as a victim authorized user to use a web application. There may be several reasons for this situation. One is the defect of the token generation algorithm, which enables the attacker to guess the tokens of other users; the other is the defect in the method of subsequent token processing, which enables the attacker to obtain other users’ tokens.
8.8.2.3. Access Control¶
The final step in handling user access is to properly decide whether to allow or deny each individual request. If the previous mechanisms are all working correctly, then the application knows the id of the user from which each received request came from, and based on that, decides whether the user is authorized to perform the requested action or access the data.
This makes it a common target for attackers due to the complexity of access control itself. Developers often make flawed assumptions about how users will interact with applications, and often omit access control checks for certain application features.
8.8.3. Input Handling¶
Many attacks on web applications involve submitting unexpected input, which results in behavior that the application designer did not expect. Therefore, a key requirement for application security protection is that it must process user input in a secure manner.
Input-based vulnerabilities can appear anywhere in an application’s functionality and are related to the type of technology it uses. For this type of attack, input validation is often a necessary defense. Commonly used protection mechanisms are as follows: blacklist, whitelist, filtering, and processing.
8.8.3.1. Blacklist¶
A blacklist contains a literal set of strings or patterns known to be used in attacks, and the validation mechanism blocks any data that matches the blacklist.
Generally speaking, this method is considered to be a poor input method. For two main reasons, a typical vulnerability in a web application can be exploited using a variety of different inputs, which can be encrypted or represented in a variety of different ways.
Second, exploit technology is constantly improving, and new methods for exploiting existing vulnerability types cannot be blocked by current blacklists.
8.8.3.2. Whitelist¶
A whitelist consists of a series of strings, patterns, or a set of criteria to match against matching input. This inspection mechanism allows data that matches the whitelist, and blocks any data other than that. This method is relatively effective, but requires better design.
8.8.3.3. Filtering¶
Filtering removes potentially malicious characters and leaves safe characters, and data-based filtering is often effective and, in many cases, serves as a general solution for handling malicious input.
8.8.3.4. Securely process data¶
Many web application vulnerabilities arise because user-supplied data is processed in an insecure way. In some cases, there are safe programming methods that avoid common problems. For example, SQL injection attacks can be organized by precompiling, and XSS can be prevented by escaping in most cases.