Shulou(Shulou.com)05/31 Report--

Today, I would like to talk to you about what the core defense mechanism of Web Application is. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

In order to prevent malicious input, applications implement a large number of security mechanisms, and these security mechanisms are similar in concept.

These security mechanisms consist of the following aspects:

1. Handle users' access to data and functions of web applications (prevent unauthorized access)

2. Handle the data entered by users on the functions of web applications (to prevent the construction of malicious data)

3. Deal with attacks (handle unexpected error reports, automatically prevent obvious attacks, automatically send alerts to administrators, maintain program access logs)

4. Manage and maintain applications

Handle access

There are usually different types of users for an application, such as ordinary users, login authentication users, and administrators. Different users' web applications are given different permissions, and they can only access different data and functions.

Web applications handle user access through three layers of interrelated security mechanisms:

1. Authentication (Authentication)

2. Session Management (Session Management)

3. Access control (Access Control)

These three mechanisms handle user access to the application, and they are also the three attack surfaces (attack surface); and all three are interdependent, resulting in unauthorized access wherever something goes wrong (bucket principle).

Authentication

Authentication is the first mechanism for handling user access, and authentication must be used unless the site has only one user.

Nowadays, most web applications use the traditional authentication model, that is, username and password.

In more secure applications such as banks, other certificates, two-factor authentication, etc., will be used to strengthen this model; in more secure applications, other authentication models such as client certificates, smart cards, or query-response mechanisms may be required.

Authentication mechanisms often require a series of other supporting functions, such as registering, forgetting passwords, changing passwords, and so on.

There are some common loopholes in the authentication mechanism, such as traversing user names, weak passwords, logic defects avoiding login, social work library query and so on.

Session management

Once verified, it is time to manage the user's session. In order to implement access control, the application needs to identify the various requests submitted by different users; to do this, the application needs to establish a session for each user and send the user a token that represents the session, the session token. The session itself is a set of data structures stored on the server to track the state of interaction between the user and the application.

Session tokens are typically passed in cookie and sometimes appear on hidden form fields or url query strings, and the session token expires for a period of time after the request is stopped.

Instead of using session tokens to identify sessions, some applications identify sessions by repeatedly submitting user certificates (as is the case with http's built-in authentication mechanism, which identifies sessions by repeatedly submitting account passwords encrypted through base64). In some cases, the 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 speculating the generation rules of session token or intercepting the session token of other users, you can access unauthorized functions and data as others.

access control

If the previous authentication and session management are working properly, the application can confirm the identity and interaction status of each user through the session token in each request, and then decide whether to agree to the user's request.

Because the requirements of typical access control are more complex, each role has different permissions, and each user is only allowed to access part of the data and functions in the application, so there are generally a large number of loopholes in this mechanism, which can cause unauthorized access.

Processing input

All user input is untrusted, and most attacks on web applications are related to the input specially constructed by the attacker, so safely dealing with user input is the key to ensure the security of the application.

Diversity of input

Web applications may perform very strict checks on some special inputs, such as length limits, character restrictions, and so on; sometimes they may need to accept arbitrary input submitted by the user; while hidden form fields and cookie are generated on the server and sent back to the client, and then sent back to the server by the user's request, in the process, the attacker can view and modify them.

Input processing method

Different treatment methods are used in different situations, or used in combination.

1. Blacklist

The blacklist contains a set of strings or patterns that will be used in the attack, and all data that matches the blacklist is blocked.

The blacklist is the worst way to input confirmation. There are two reasons:

1) user input can be bypassed by various encodings or other representations, such as omitting some characters that have the same effect. For example, alert ('xss') is blocked, and prompt (' xss') can also be used. For example, web application firewalls are often subject to null attacks because strings are handled differently in managed and unmanaged situations.

2) with the rapid development of technology, it has produced some new methods of vulnerability exploitation.

2. Whitelist

The whitelist contains a set of benign strings, patterns, or a set of criteria. All data that does not match the whitelist will be blocked.

The whitelist is the best way to enter confirmation, because specifying a whitelist leaves only secure strings, and the attacker cannot construct the input.

But the whitelist has its limitations. In many cases, web applications must accept characters that do not meet security standards. For example, the application requires users to register with their real names, but the names contain hyphens, apostrophes and other characters that may attack the database. Therefore, the whitelist has limitations and is not a panacea for unsafe input.

3. Purification

This approach solves the part of the whitelist that cannot be dealt with. It accepts some data inputs that cannot be secured, but purifies them, such as deletion, escape, encoding, etc.

Decontamination can be used as a general method, but it should be noted that if an input needs to contain several possible malicious data, it can be effectively evolved. You need to use boundary confirmation at this point.

4. Secure data processing

Handling data submitted by users in an insecure manner is the root cause of many vulnerabilities in web applications.

Secure data processing does not need to worry about the confirmation of user input data, but to ensure the absolute security of the processing process. For example, parameterized queries that prevent sql injection.

However, this method does not apply to every task that a web application needs to perform, and if applicable, it is a common way to deal with malicious input.

5. Logic check

In some vulnerabilities, the input of the attacker is exactly the same as that of the normal user, but the motive is different. In this case, the above mechanism is almost completely ineffective. For example, attack the account submitted by modifying the hidden form field in an attempt to access other user accounts. At this point, no amount of input confirmation can distinguish the data between the attacker and the normal user. To prevent unauthorized access, the application must confirm that the submitted account belongs to the user who previously submitted the account.

Boundary confirmation

Given the nature of the core security problem (none of the user input can be trusted), you can use the Internet (untrusted) and the server application (trusted) as the boundary, and then purify all input from the Internet at the border. the purified data is given to the server application. The above is a simple boundary validation, and when analyzing the actual vulnerabilities, it is found that it is not enough to perform this simple input validation.

Based on the universality of application execution functions and the diversity of technologies adopted, a typical application needs to defend against a large number of various input attacks, each of which may use a completely different specially designed data. therefore, it is difficult to establish a simple mechanism at the external boundary to defend against all attacks.

Many application functions are designed to combine a series of different processes, and one input from the user may perform many operations in many components, where the output of the previous operation is used for the latter operation. The converted data is completely different from the original input. Experienced attackers can take advantage of this difference to generate malicious data in critical steps to attack components that receive data. Therefore, it is difficult to establish a simple mechanism on the outer boundary to defend against all attacks.

Boundary confirmation is a more effective model. The boundary here is not limited to the boundary between the Internet and web applications. Every component or functional unit of a web application has a boundary. In this way, each component can defend against the special type of specially designed input it receives. When the data passes through different components, a confirmation check can be performed on the previously generated data, and since different validation checks are performed at different stages of processing, there can be no conflict between them.

For example, the following figure:

Multi-step confirmation and standardization

During the confirmation check, there is a problem that the input mechanism often encounters when the user's input needs to be processed in several steps. This problem occurs when an application tries to purify user input by deleting or encoding certain characters. If this problem is not handled carefully, the attacker can construct specialized input so that malicious data can successfully bypass the confirmation mechanism. For example, double write bypass, step execution sequence bypass.

Data normalization can cause another problem. In order to transmit some unusual characters and binary data through http, it is usually normalized by encoding, but how to decode it after filtering, attackers can encode to avoid the confirmation mechanism.

In addition to the standard encoding scheme used by web applications, this can also cause normalization problems if the components of the application convert data from one character set to another. For example, blocks and routers are converted to Y and A, which is often used by attackers to transmit blocked characters and keywords.

Sometimes it is difficult to avoid problems caused by multi-step validation and normalization, and there is no only solution to such problems. How is it possible to generally avoid purifying bad input and reject it completely.

Deal with an attack

We have tried our best to prevent the intrusion of attackers, but without an absolutely secure system, how should web applications respond to attacks if security events occur? generally speaking, the following measures are taken:

1. Deal with unexpected errors

2. Automatically block obvious attacks

3. Automatically send an alert to the administrator

4. maintain the access log of the program

Handling error

One of the key mechanisms of an application is how to handle unexpected errors. Generally in a production environment, the application should not return any system-generated or other debugging information to the user. For attackers, this information provides a good reference for the next attack. And unexpected errors often point to flaws in the program's defense mechanism. The error handling mechanism is usually integrated with the logging mechanism.

Deal with an attack

Many attacks send a large number of common malicious characters, and applications should take automatic response measures to prevent the attacker from probing. Such as terminating a session, requiring re-login, disabling ip, etc.

Maintenance log

The log records the intrusion, and the intrusion process can still be restored after the intrusion.

Important application logs should record all requests. In general, at least the following items should be included:

1. All authentication-related events, such as successful or failed logins, password changes

2. key operations, such as money transfer, etc.

3. Requests blocked by access control

4. Contains a known attack string

The log records the time, ip, and user account of each event. Logs need to be strictly protected from unauthorized reads. Write, modify, etc.

Logs can also become an attack surface, for example, logs that can be accessed without authorization provide the attacker with sensitive information such as session tokens, request parameters, and so on.

Alert the administrator

The core problem is false positives and false positives. Some improvements can be made by combining alarm mechanism with confirmation mechanism and other control methods.

Generally speaking, the abnormal events monitored include the following:

1. Abnormal application, such as receiving a large number of requests from an ip

2. Abnormal transactions, such as the abnormal amount of funds transferred into and out of a bank account.

3. Contains a known attack string

4. The data that cannot be viewed by ordinary users in the request is modified.

Manage the application

The administrator can help administrators manage user accounts and roles, apply monitoring and audit functions, perform diagnostic tasks, and configure various functions of the application.

The management mechanism is one of the main attack areas of the application, and the management mechanism often has high permissions. When you get the control of the management mechanism, you get the control of the application. And there are often some obvious loopholes and sensitive functions in the management mechanism. Loopholes in obtaining administrator privileges generally appear in the processing of user access mechanisms, such as unauthorized access, weak passwords, and so on. If the management background can handle requests sent by ordinary users, you can try xss vulnerabilities to hit the background blindly.

After reading the above, do you have any further understanding of what is the core defense mechanism of Web Application? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.