To prevent malicious input, applications implement a large number of security mechanisms, and these security mechanisms are conceptually similar.
These security mechanisms consist of the following aspects:
1. Processing user access to data and functions of web applications (preventing unauthorized access)
2. Process the data input by users to the web application function (prevent the construction of malicious data)
3. Respond to attacks (handle unexpected error reports, automatically block obvious attacks, automatically send alerts to administrators, Maintenance program access log)
4. Management and maintenance of applications
Usually there are different types of users for an application, such as ordinary users, Log in to verify users and administrators. Different permissions are given to different user web applications so that they can only access different data and functions.
Web applications handle user access through three interrelated security mechanisms:
1. Authentication
2. Session management (Session Management)
3. Access Control
These three mechanisms handle user access to applications, and they are also three attack surfaces. ); and these three are interdependent and indispensable. No matter where there is a problem, unauthorized access will occur (barrel principle).
Authentication is the first mechanism to handle user access. Unless the website has only one user, authentication must be used.
Most web applications today use the traditional authentication model, that is, username and password.
In applications with higher security requirements such as banking, other certificates, two-factor authentication, etc. will be used to strengthen this model; in applications with higher security requirements, client certificates, smart cards or queries may be required -Answer mechanisms and other authentication models.
Authentication mechanisms often require a series of other support functions, such as registration, forgotten password, password change, etc.
There are some common vulnerabilities in the authentication mechanism, such as user name traversal, weak passwords, logical flaws to avoid login, social engineering database query, etc.
After passing the verification, it is time to manage the user's session. In order to implement access control, the application needs to identify various requests submitted by different users; to do this, the application needs to establish a session for each user and send a token representing the session, that is, a session token, to the user. The session itself is a set of data structures stored on the server that track the interaction state between the user and the application.
Session tokens are generally passed in cookies, and sometimes appear on hidden form fields or URL query strings. Session tokens will expire within a period of time after stopping the request.
Some applications do not use session tokens to identify sessions, but instead identify sessions by repeatedly submitting user certificates (this is the case with http's built-in authentication mechanism, which identifies sessions by repeatedly submitting account passwords encrypted with base64). In some cases, session information is not saved on the server, but on the client. In order to prevent users from modifying it, it is generally encrypted.
The attack surface of session management is the session token itself. By inferring the generation rules of the session token or intercepting the session tokens of other users, you can access unauthorized functions and data as others.
If the previous authentication and session management are running normally, the application can confirm the identity and interaction status of each user through the session token in each request, so it Can decide whether to agree to the user's request.
Because the requirements of typical access control are relatively complex, each role has different permissions, and each user is only allowed to access a part of the data and functions in the application. Therefore, there are generally a large number of loopholes in this mechanism, which can cause future Authorized access.
All user input is not trustworthy. Most attacks on web applications are related to specially constructed input by attackers. Therefore, securely processing user input is the key to protecting the application. Key to program security.
Web applications may perform very strict checks on some special inputs, such as length limits, character limits, etc.; sometimes they may need to accept any input submitted by the user ; However, hidden form fields and cookies are generated on the server and sent back to the client, and then sent back to the server by the user's request. During this process, the attacker can view and modify them.
Use different processing methods in different situations, or use them in combination.
1. Blacklist
The blacklist contains a set of strings or patterns that will be used in attacks. All data matching the blacklist will be blocked.
Blacklist is the least effective method for input confirmation. There are two reasons:
1) User input can be bypassed through various encodings or other forms of expression, such as missing some characters that have the same effect. For example, if alert('xss') is blocked, you can also use prompt('xss'). For example, web application firewalls are often subject to null byte (null) attacks. This is because strings are processed differently in managed and unmanaged situations. .
2) The rapid development of technology has resulted in some new methods of exploiting vulnerabilities.
2. Whitelist
The whitelist contains a set of benign strings, patterns or a set of standards. All data that does not match the whitelist will be blocked.
Whitelist is the most effective method for input confirmation, because only safe strings will be left when specifying the whitelist, and attackers cannot construct input.
But whitelist has limitations. In many cases, web applications must accept some characters that do not meet security standards. For example, the application requires users to register with their real names, but the names contain some hyphens, apostrophes, and other characters that may cause attacks on the database. Therefore, whitelisting has limitations and is not a universal solution to unsafe input.
3. Purification
This method solves the problem that the white list cannot handle. It accepts some data input that cannot guarantee security, but will purify it, such as deleting, escaping, Encoding and other
purification can be used as a general method, but it should be noted that if an input item needs to accommodate several possible malicious data, it can be effectively evolved. In this case, boundary confirmation is required.
4. Secure data processing
Handling user-submitted data in an unsafe manner is the root cause of many web application vulnerabilities.
Safe data processing method does not need to worry about confirming user input data, but instead ensures the absolute safety of the processing process. For example, parameterized queries to prevent sql injection.
But this method does not apply to every task that a web application needs to perform. If applicable, it is a general method for handling malicious input.
5. Logic check
In some vulnerabilities, the input of the attacker and the normal user are exactly the same, but the motivation is different. In this case, the above mechanism is almost completely ineffective. For example, attacking an account submitted by modifying a hidden form field in an attempt to access other user accounts. At this point, no amount of input confirmation can distinguish the attacker's data from that of normal users. To prevent unauthorized access, the application must confirm that the submitted account belongs to the user who previously submitted the account.
Given the nature of the core security problem (all user input is untrusted), the boundary between the Internet (untrusted) and the server application (trusted) can be used as a boundary, and then Sanitize all input from the Internet at the boundary and pass the sanitized data to the server application. The above is a simple boundary confirmation. When analyzing actual vulnerabilities, it was found that performing this simple input confirmation is not enough.
Based on the breadth of application execution functions and the diversity of technologies used, a typical application needs to defend against a large number of various input attacks, each of which may use a completely different specialized Design data, so it is difficult to establish a simple mechanism at the external boundary to defend against all attacks.
Many application features are designed to combine a series of different processes. One user input may perform many operations in many components, where the output of the previous operation is used in the subsequent operation. The data is transformed and completely different from the original input. However, experienced attackers can take advantage of this difference to generate malicious data at critical steps and attack the components that receive the data. Therefore, it is difficult to establish a simple mechanism at the external boundary to defend against all attacks.
Boundary confirmation is a more effective model. The boundary here is no longer limited to the boundary between the Internet and the web application. Each component or functional unit of the web application has boundaries. In this way, each component can defend itself against the particular type of specially designed input it receives. When the data passes through different components, validation checks can be performed on the previously generated data, and since different validation checks are performed at different stages of processing, there is no possibility of conflicts between them.
For example, the following picture:
In the confirmation check process, when it needs to be processed in several steps When the user inputs, there will be a problem that the input mechanism often encounters. This problem occurs when an application attempts to sanitize user input by removing or encoding certain characters. If this problem is not handled carefully, an attacker can construct specialized inputs so that malicious data can successfully avoid the confirmation mechanism. For example, double-write bypass and step execution order bypass.
Data normalization creates another problem. In order to transmit some uncommon characters and binary data through http, they are usually normalized through encoding. However, if decoding is performed after filtering is implemented, the attacker can avoid the confirmation mechanism through encoding.
In addition to the standard encoding schemes used by web applications, other cases can also cause normalization problems if components of the application convert data from one character set to another. For example, Ÿ and  are converted to Y and A. Attackers often use this method to transmit blocked characters and keywords.
Sometimes it is difficult to avoid problems caused by multi-step confirmation and standardization, and there is no single solution to such problems. How is it possible to generally avoid sanitizing bad input and instead reject such input altogether.
We have tried our best to prevent attackers from intruding, but there is no absolutely safe system. If a security incident occurs, how should the web application respond to the attack? What are the handling measures? Generally, they are as follows:
1. Handle unexpected error reports
2. Automatically block obvious attacks
3. Automatically send alerts to administrators
4. Maintain program access logs
Handling errors
A key mechanism of an application is how to handle unexpected errors. Generally in a production environment, applications should not return any system-generated information or other debugging information to the user. This information provides attackers with good reference information for the next attack. And unexpected errors often point to some flaw in the program's defense mechanisms. Error handling mechanisms are often integrated with logging mechanisms.
Responding to attacks
Many attacks will send a large number of common malicious characters. In such cases, applications should take automatic response measures to prevent attackers from detecting. For example, terminate the session, require re-login, ban IP, etc.
Maintenance log
The log will record the intrusion situation, and the intrusion process can still be restored after the intrusion.
Important application logs should log all requests. Generally, it should include at least the following items:
1. All authentication-related events, such as successful or failed logins, password changes
2. Key operations, such as Transfers, etc.
3. Requests blocked by access control
4. Containing known attack strings
The log will record the time, IP, User Account. Logs need to be strictly protected from unauthorized reading. Writing, modifying, etc.
logs will also become an attack surface. For example, logs that can be accessed without authorization will provide attackers with sensitive information such as session tokens, request parameters, etc.
Alert to administrators
The core problem is false positives and false negatives. Some improvements can be achieved by combining the alert mechanism with the confirmation mechanism and other control methods.
Generally speaking, the abnormal events monitored include the following:
1. Application abnormality, such as receiving a large number of requests from an IP
2. The transaction is abnormal, such as the amount of funds transferred in and out of a bank account is abnormal
3. Contains known attack strings
4. The data in the request that cannot be viewed by ordinary users is modified
Management application can help administrators manage user accounts and roles, apply monitoring and auditing functions, perform diagnostic tasks and configure various application functions.
Management mechanisms are one of the main attack surfaces of applications, and management mechanisms often have very high permissions. Gaining control of the management mechanism is gaining control of the application. Moreover, there are often some obvious loopholes and sensitive functions in the management mechanism. Vulnerabilities that gain administrator permissions generally occur in the user access mechanism, such as unauthorized access, weak passwords, etc. If the management background can handle requests sent by ordinary users, you can try to blindly type the XSS vulnerability in the background.
The above is the detailed content of What is the core defense mechanism of Web Application?. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
