introduction of remote code injection and code defense

Web applications use operating system calls to execute native images to extend their functionality or run legacy code. Needless to say, user input directly arriving at these calls is of course extremely dangerous, because in this way, malicious users can use the credentials of the application host to run native code, or even cause complete system damage. User input propagated to shared library loading methods (such as Java. Lang. runtime. Loadlibrary) is also dangerous and should be avoided. Even if the user controls only the image parameters and does not control the image to be loaded, precautions must be taken because the performer (such as command shell) may allow command binding or pipeline tasks. In addition, we need to pay attention to the problem of "path traversal". Here is the vulnerable java code:

Similar asp.net example:

In the above example, a malicious user can inject two points ("...") to separate the separate environment.

The remedy to some problems is to clean up the user input. By verifying that user input does not contain dangerous characters, it is possible to prevent malicious users from allowing your application to run unplanned operations, such as enabling arbitrary SQL queries, embedding JavaScript code running on the client, running various operating system commands, and so on.

1 it is recommended to filter out all the following characters

[1] | (vertical sign)

[2] & symbol

[3] ; (semicolon)

[4] $(dollar sign)

[5] % (percent sign)

[7] '(single quotes)

[8] "(quotation mark)

[9] \ '(backslash escape single quotation mark)

[10] \ "(backslash escape quotes)

[11] (angle bracket)

[12] () (brackets)

[13] + (plus)

[14] Cr (carriage return, ASCII 0x0D)

[15] LF (line feed, ASCII 0x0a)

[16] , (comma)

[17] \ (backslash)

Alternative remedies verify that uncleaned inputs are harmless.

2 good user input verification mechanism

[1] Frontal validation - compares user input to a known set of acceptable values (white name list), ranges, or regular expressions. If no match is found, reject the input in the appropriate way.

[2] Indirect selection - does not use user input directly. User input should be treated as a key in the hash table of acceptable values.

[3] Message authentication code (MAC) - if you need to allow dynamic instantiation of values, you can use HMAC to protect them.

This kind of MAC is calculated by running the encryption hash function on the value of the connected key. After the HMAC is attached to the request, when the request is received and verified, the HMAC can be used. This ensures that the integrity and authenticity of the values are valid and not forged by malicious users. Given the key and data, this function (written in Java) generates an HMAC

3 verify the following properties entered by the user

[1] Parameter type

[2] Parameter length

[1] Clean up input to exclude symbols that are meaningful for executing operating system commands, such as:

[a] | (vertical sign)

[b] & symbol

[c] ; (semicolon)

[d] (point)

[2] If possible, run the web application in an environment that changes the root directory

[3] Do not let the user specify the native image to load directly. If multiple selections are required, use the white name list, indirect selection, or HMAC.

4 code injection

[1] Clean up dangerous characters entered by users. The character set to be cleaned up will vary depending on the language of evaluation and the context of the input in the evaluated expression.

[2] Avoid using user controlled data to call script evaluators

[3] Use positive validation mechanism (pattern matching).

5 soap operation

[1] Avoid passing user controlled input to sensitive soap related calls

[2] Apply positive validation mechanism (pattern matching).

[3] Clean up user input. It is recommended that you filter the following characters or convert them to escaped XML equivalents:

[a] (angle bracket)

[b] "(quotation mark)

[c] '(single quotes)

[d] & symbol

[4] If you can, put user input in the CDATA section (that is, user input is characters). The CDATA section instructs the XML engine to avoid parsing the data it contains. However, don't forget to filter out or escape CDATA termination text strings ("]]").

The following are Java specific mechanisms for cleaning user input and Java implementation of the above general mechanisms:

[1] No need to reprocess all

In most cases, the necessary clean-up capacity has been implemented. Apache stringescapeutils (part of Apache commons Lang) has implemented various target cleanup methods (including HTML, XML, SQL, and so on). However, if you have not implemented the necessary cleanup methods, you can write your own cleanup functions. Here's how to avoid cross site scripting:

[2] Automatic frame cleaning

[3] Servlet filter

Reference A. Apache commons Lang (including stringutils) -

B. Apache Struts －

The following are the Java specific mechanisms for verifying user input and the Java implementation of the above general mechanisms:

[1] Positive verification

[a] White name list

[b] Pattern matching

Compare the input with the expected pattern. For example, if the username field should only allow alphanumeric characters and be case insensitive, use the following regular expression: ^ [a-za-z0-9] * $, Java 1.3 or earlier does not contain any regular expression packages. It is recommended that the Apache regular expression package (see resources below) be used with Java 1.3 to address this lack of support. Example of performing regular expression validation:

Java 1.4 introduces a new regular expression package (Java. Util. Regex). Here is a revised version of validator.matchpattern, using the new Java 1.4 regular expression package:

[c] Scope validation

The following example verifies that the input numberofchoices is between 10 and 20:

[2] Indirect selection

The following code segments implement the above user input verification "indirect selection" mechanism under J2EE:

[3] Message authentication code (MAC)

Under J2EE, the following functions implement the above user input validation HMAC mechanism: after the key and data are given, this function generates an HMAC:

The following code uses the above functions to defend against "connection manipulation":

[4] Java SecurityManager

With Java's security manager, you can fine tune which APIs the JVM can access and how to access (that is, which parameters to use). Define a policy file to define security restrictions.

Here is a short list of the different license types available in Java with brief descriptions of each type:

AllPermission - all permissions are granted and should be used with caution

Audiopermission - grant access to audio system resources

Awtpermission - grants access to various AWT (Abstract window toolbox) resources, such as clipboard and screen

Filepermission - grant access to file related operations

Netpermission - grant access to various network operations

Propertypermission - grant access to various Java properties such as "Java. Home" and "OS. Name"

Reflectpermission - grant access to the reflection operation

Runtimepermission - grant access to runtime related operations (such as exiting VM, loading native library, etc.)

Securitypermission - grants access to security related operations, such as controlling the securitymanager itself.

Serializablepermission - grants access to serialization operations, such as replacing objects during serialization or marshalling

Socketpermission - grants network operation access through a socket.

Sqlpermission - grants access to functions related to version SQL records.

Here is an example of how to grant access to code in C: \ code to abort a VM:

By default, Java's securitymanager is turned off. You can activate the JVM by running it with the "Java. Security. Manager" flag.

There are two default policy files: system policy file (under Java. Home \ lib \ security \ Java. Policy) and user policy file (under user. Home \. Java. Policy)

You can also specify other or different policy files. This can be done by triggering the "Java. Security. Policy" flag next to the filename when the VM is running.

If you want to activate Security Manager in tomcat, you should specify the - Security command-line argument when running catalina.bat or catalina.sh. The policy file is located in Catalina? Home / Lib

[1] Type check

Then there is the implementation of Java's digital (int) type verification function:

The main Java data types the application should handle:

- Byte

- Short

- Integer

- Long

- Float

- Double

- Date

[2] Length verification

Java string length validator implementation:

1 remote execution code

[1] Use Java's security manager to determine the list of allowed white names for the target.

2 resource injection

[1] Take advantage of Java's security manager.

For example, by specifying the following "grant" rules, you can restrict the ports that an application binding can bind:

3 code injection

[1] Implement positive verification mechanism (pattern matching)

The following J2EE code demonstrates how an expression that submits an evaluation contains only the specific character set required for a simple calculation:

4 soap operation