On Web security trends and core defense mechanisms

A. Why Web security technology is generating

Early on: The World Wide Web (Wide) consists only of Web sites, which are basically repositories of static documents. This information flow is transmitted only by the server to the browser one-way. Most sites do not validate the legality of the user.

Today: already quite different from the earlier World Wide Web, most sites on the Web are actually applications. They are powerful and deliver two-way information between the server and the browser. Much of the information they deal with is private and highly sensitive information. As a result, security issues are critical and web security technologies emerge.

two. Common vulnerabilities in Web programs

(1) Imperfect authentication measures: Such vulnerabilities include various flaws in the application login mechanism, which may allow attackers to break passwords that are not strong, unleash brute force attacks, or avoid landing altogether.

(2) Imperfect access control measures: This issue involves situations where an application cannot provide full protection for data and functionality, and an attacker can view other users to save sensitive information from the server or perform privileged operations.

(3) SQL injection: This vulnerability allows an attacker to submit specially crafted input that interferes with the interaction of the application with the back-end database. An attacker could extract any data from the application, destroy the logical structure, or execute commands on the database server.

(4) Cross-site scripting: An attacker could exploit this vulnerability to attack other users of an application, access their information, perform unauthorized operations on their behalf, or launch other attacks against them.

(5) Information disclosure: This problem includes application disclosure of sensitive information that attackers use to exploit sensitive information through faulty error handling or other behavioral attacks on the application.

three. Core Security Issues

The core security issue for today's web programs is that users can submit arbitrary input. The specific:

(1) The user may intervene in all data transmitted between the client and the server, including request parameters, cookies and HTTP headers.

(2) Users can send requests in any order.

(3) Users are not limited to accessing applications using only one Web browser. A wide variety of tools can assist in attacking Web applications, which can be integrated in the browser or independently of the browser. These tools can make requests that the General browser cannot provide, and can quickly generate a large number of requests to find and exploit security issues for their own purposes.

Four. At present, the core defense mechanism for Web security issues

Basic security issues for Web applications (all user input is not trusted) cause applications to implement a number of security mechanisms to protect against attacks. Although the design details and execution efficiency may vary widely, the security mechanisms used by almost all applications are conceptually similar.

The defense mechanisms used by Web applications are composed of several core factors.

(1) Handle the data and functions of the user accessing the application, and prevent the user from obtaining unauthorized access.

(2) Handle user input to the application function, prevent bad behavior by wrong input.

(3) Handle attackers to ensure that the application is functioning as a direct target and take appropriate defenses and attacks to thwart attackers

(4) Manage the application itself to help administrators monitor their behavior and configure their capabilities.

Five. Theoretical concrete measures

For the above four reasons, there are a number of theoretical approaches:

5.1 Handling User Access

Almost any application must meet a central security requirement to process users ' access to their data and functionality. Most Web applications handle user access using a three-tier, interrelated security mechanism:

(1) authentication

(2) Session Management

(3) Access control

5.2 Handling User Input

In many cases, applications may have very strict validation checks on some special inputs. For example, the maximum length of a user name that is submitted to the login feature is 8 characters and can contain only letters.

In other cases, the application must accept more extensive input. For example, the Address field that is submitted to a personal information page can legally contain letters, numbers, spaces, hyphens, apostrophes, and other characters. However, you can still enforce a valid limit on this field. For example, the data submitted must not exceed an appropriate length limit (such as 50 characters) and must not contain any HTML markup (HTML mark-up).

Several methods of input processing:

(1) "Reject known bad input"

(2) "Accept known normal input"

(3) Purify the input data: The data may exist in the malicious characters are completely removed, leaving only known safe characters, or further processing before they are properly encoded or "escaped."

(4) Secure data processing: Handling user-submitted data in an unsafe manner is the root cause of many Web application vulnerabilities. There are times when you can use a secure programming approach to avoid common problems.

(5) Grammar check: In order to prevent unauthorized access, the application must confirm that the submitted account belongs to the user who submitted the account before.

(6) Boundary confirmation: Where the server-side application first receives user data is an important trust boundary where the application needs to take steps to defend against malicious input.

5.3 Necessity of boundary confirmation

When we begin to analyze some actual vulnerabilities, it is not enough to perform this simple input acknowledgement because:

(1) based on the breadth of functions performed by the application and the diversity of technologies used, a typical application needs to defend against a large variety of input-based attacks, and each attack may take a distinct set of specially designed data, making it difficult to establish a separate mechanism at the external boundary to defend against all these attacks.

(2) Many application functions involve combining a series of different types of processes.

(3) Defending against different types of input-based attacks may require a variety of validation checks on conflicting user inputs. For example, preventing cross-site scripting attacks might require the ">" character HTML to be encoded as ">", while preventing command injection attacks would require the inclusion of & with; The input of the character. Sometimes it is almost impossible to want to block all types of attacks while at the external boundary of the application.

Boundary confirmation (boundary validation) is a more efficient model. At this point, each individual component or functional unit of the server-side application treats its input as input from a potentially malicious source. In addition to the external boundary between the client and the server, the application performs data validation on each of these trust boundaries. This model provides a solution to the problems raised earlier. Each component can defend against the special types of specially designed input it receives. When the data passes through different components, a validation check is performed on any data values that were generated during the previous conversion. Furthermore, there is no possibility of conflict between them due to different validation checks performed at different processing stages.

5.4 Multi-Step confirmation and normalization

To defend against certain cross-site scripting attacks, an application may remove an expression from any user-submitted data: <SCRIPT>, but an attacker could circumvent the filter:<scr<script>ipt> by applying the following input. Since filtering cannot be run recursively, the data around the expression is merged and the malicious expression is re-established after the blocked expression is deleted. Similarly, if you perform several confirmation steps on user input, attackers can use the order of these steps to avoid filtering. For example, if the application first removes the script tag recursively and then removes the quotation marks, you can use the following input to circumvent the confirmation check:<scri*ipt>.

Data canonicalization can cause another problem. When the user's browser sends the input, it can encode the inputs in various forms. These encoding schemes are used to enable the safe delivery of uncommon characters and binary data over HTTP. Normalization refers to the process of transforming or decoding data into a common character set. If normalization is performed after input filtering is implemented, an attacker can bypass the acknowledgement mechanism by using encoding. For example, an application might remove an apostrophe from user input to prevent some SQL injection attacks. However, if the application then normalizes the purified data, the attacker can bypass the acknowledgment using the URL-encoded input.

Sometimes it can be difficult to avoid the problems caused by multi-step validation and normalization, and there is no single solution to such problems.

One workaround is to perform a cleansing operation recursively until the input cannot be modified further. If possible, it is best to avoid the practice of clearing some bad input, rejecting this type of input altogether.

5.5 Handling attackers

The measures taken to deal with attackers are generally composed of the following tasks:

(1) Handling Errors

(2) Maintain audit log

(3) Alert the Administrator

(4) Responding to attacks

5.6 Handling Errors

A critical defense mechanism for an application is to properly handle unforeseen errors, either to correct them or to send the appropriate error message to the user. In a re-production environment, an application should not return any system-generated messages or other debugging information in its response. Overly detailed error messages are very helpful for malicious users to launch further attacks on the application. In some cases, an attacker is able to obtain sensitive information from an error message using an error-handling method that is present, and an error message becomes an important channel for an attacker to steal data from an application.

Most Web development languages provide good error handling support through Try-catch blocks and checked exceptions. Application code should use these methods extensively to identify special and routine errors and to handle them accordingly. Also, most application servers can be configured to handle unhandled application errors in a customized manner, such as providing error messages that do not contain too much information.

5.7 Maintaining audit logs

The audit log (audit log) plays a significant role in investigating intrusion attempts against an application. After an intrusion, a valid audit log function helps the application owner understand what actually happened.

In any security-focused application, logs should record all important events. In general, these events should include at least the following items.

(1) All authentication function related events, such as successful or failed logins, password modification.

(2) Key transactions, such as credit card payments and transfers

(3) Any request that contains a known attack string that blatantly indicates malicious intent.

5.8 Alerting the Administrator

Audit logs can help application owners investigate intrusion attempts and, if possible, take legal action against intruders. The abnormal events of alarm monitoring typically include the following points:

(1) Application anomalies, such as receiving a large number of requests from a single IP address or user, indicating that the application is being subjected to a custom attack

(2) Abnormal trading: The amount of money transferred or transferred out of a single bank account

(3) Request with a known attack string

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

5.9 Managing Applications

Many applications typically perform administrative functions internally through the same Web interface, which is also its core non-security feature, in which case the management mechanism becomes the main attack surface of the application. The main attraction of the attacker is that it can elevate permissions, for example:

1. The weaknesses of the authentication mechanism allow attackers to gain administrator privileges and quickly compromise the entire application.

2. Many applications do not perform effective access control on some of its administrative functions. Exploiting this vulnerability, an attacker could create a new user account with powerful privileges.

3. Management functions are often able to display data provided by ordinary users. Any cross-site scripting flaw that exists in the interface can compromise the security of the user session

4. Management functions are often not rigorously tested for security because administrative users are considered trusted users, or because penetration testers can only access low-privileged accounts. Moreover, he usually needs to perform quite dangerous operations, including accessing files on disk or operating system commands. If an attacker is able to break the management function, it can be used to control the entire server.

On Web security trends and core defense mechanisms