IMCAFS

 Home

the third part: file path manipulation, system log spoofing, thread security and resource not released in java web project

Posted by santillano at 2020-04-12
all

Java Web engineering source code security audit practice, Part 3

Series content:

This is the third part of the series: Java Web engineering source code security audit practice, Part 3

https://www.ibm.com/search/csass/search/?q=Java%2BWeb%2B%E5%AE%89%E5%85%A8%E5%AE%A1%E8%AE%A1%E5%AE%9E%E6%88%98%2B%E5%8F%B6%E6%9E%97&dws=cndw&ibm-search.x=-655&ibm-search.y=-329&ibm-search=Search&sn=dw&lang=zh&cc=CN&ddr=&en=utf&lo=zh&hpp=20

Look forward to the rest of the series.

This content is part of this series: Java Web engineering source code security audit practice, Part 3

Look forward to the rest of the series.

Preface

This paper is the third part of Java Web project source code security audit practice. Based on the webgoat project, it explains four high-risk vulnerabilities: file path manipulation, system log spoofing, thread security and resource not released. The focus is on the source audit ideas and the actual combat of attack and defense drill.

File path manipulation of web application threat

Technical principle

When an attacker can specify file operation parameters such as file name and file path, it is possible to access system resources unreachable under normal circumstances.

Problem analysis pathbasedaccesscontrol.java129

Source code audit found that pathbasedaccesscontrol.java line 129 file() method. It is possible for an attacker to control file path access or modify other protected files. The contents of the file are displayed as page elements.

Figure 1. Problem code snippet

click to enlarge

In the deployed webgoat project, start the production environment. Log in as an attacker, click "access control flags - bypass a path based access control scheme" in the left navigation directory, select any xx.html file in combox, and click "view profile" to submit.

Attack scenario

Figure 2. File path manipulation attack scenario

click to enlarge

Solution

Quick repair

To solve the problem of file path manipulation in the example of webgoat project, you can add the verification of file path in line 97 of pathbasedaccesscontrol.java. The code snippet is as follows:

Figure 3. Code for path manipulation of rectification file

click to enlarge

Deploy the rectified code, rerun the attack scenario, and do not reproduce the attack.

Infer other things from one fact

Generally, in order to prevent the problem of file path manipulation, developers should first use the correct system functions, then can customize the filtering of file operation parameters according to the needs, and can also use the server security access framework. The following five ideas are provided:

1. use the specification path getCanonicalPath ()

An attacker can use parameters containing the.. / sequence to specify files located outside a specific directory, thus violating the program security policy and causing a path traversal vulnerability. An attacker may upload files to any directory.

The operations of Java language on path include getabsolutepath() to get the absolute path and getcanonicalpath() to get the specification path. Getcannonicalpath() first converts the pathname to an absolute pathname, which is the same as calling the getabsolutepath() method. It is then mapped to its unique pathname in a system related way. This usually involves removing redundant names (such as "." and ".."), analyzing symbolic connections (for UNIX platforms), and converting drive letters to standard case (for Microsoft Windows Platforms). Therefore, we should try our best to use standard path to avoid redundant analysis symbols that may be used by attackers.

2. The developer performs input verification for the used file operation parameters and filters characters (such as "." and "..")

3. Limit file types for application scenarios. For example, the image file used can only be suffix. PNG,. JPG, but not. Bat,. Sh. It is suggested to strengthen the judgment of files by the file header rather than the file suffix.

4. Java Security Manager permission java.io.filepermission

5. Server security configuration policy file. It can limit the files that can be read to a specific directory. How to configure the security policy file depends on the type of server used

Log spoofing and privacy disclosure of web application threats

When it is possible for an attacker to write log information, it is possible to construct false information, confuse log readers, and confuse system operation and maintenance debugging personnel to debug system faults. Log spoofing can help attackers to conduct large-scale sustainable attack (APT).

The source code audit found that line 271 of hammerhead.java recorded an unchecked message. The code fragment is as follows:

Figure 4. Problem code snippet

click to enlarge

In the deployed webgoat project, start the production environment.

Simulate the attacker's login, click "injection flags - log spoofing" in the left navigation directory, and enter "Smith% 0d% 0alogin succeeded for username: admin" in the text box. After submitting, assume that the server log text will write the false information "succeeded for username: admin”。 The trick of the attack is to wrap the symbol \ n, which is% 0d% 0A after transcoding. Wrapping makes the spoofing information in the log look more real.

This sample project of webgoat is only a descriptive presentation, and there is no real code execution to write server logs.

Solution

1. Line break "\ n". The key element of log spoofing is line break. If log information is filtered by blacklist, "\ n" must appear in the blacklist. If log information is filtered by white list, "\ n" must not appear in the white list

2. After the development, before the production environment goes online, delete system. Out ()

3. Hierarchical log switch. Software development version and release version, turn on the log switch of different levels, record clearly and reduce the harm to the minimum range

4. Control log content. Do not record sensitive information of users in any way, even encrypted

5. Do not record privacy information. When the user's privacy information is written to the log, it causes privacy disclosure. In particular, password information, even after encryption, should not be stored in the log. Because any encryption algorithm can be broken

The webgoat project demonstrates dozens of cases of Web problems, such as uploading and executing malicious files. This article is limited in length and does not list other cases one by one.

We talked about the audit of Web high-risk vulnerabilities. Here are a few programming mistakes that developers can easily make due to Java language features. These code defects make the project not robust and require fixed-point audit and rectification.

Thread safety of Java and JSP code defects

The essence of thread synchronization problem is to share static variables globally, which results in two browsers under the same thread affecting each other. For example, click the submit button of a and B browser in a quick and continuous manner. If the modification of static variables by B happens after the modification of static variables by a and before the generation of reply content of page a, the page content related to browser a and shared global variables can be overwritten by the page content of browser B submitted later. This is against the developer's intent. If it is an e-commerce website, there is thread synchronization problem in the price of goods, which may cause a user to buy expensive goods at a low price.

Thread safety problems can be hidden deeply, which can not be found by unit tests. Because the program is executed at the machine time level, it is difficult for an attacker to interrupt the thread at a suitable point in time. However, if we design advanced attack scenarios, first use denial of service attack DDoS to consume system resources, making the program run slowly (webgoat project is simulated with sleep function), then the problem is highlighted. Thread security issues need to be examined in the security development and code audit phases.

The source code audit found that threadsafetyproblem.java defines the static variable currentuser in line 59, and the code snippet is as follows:

Figure 5. Problem code segment definition static variables

click to enlarge

In line 92 of threadsafetyproblem.java, there is a sleep time of 1.5 seconds before using currentuser, which may cause currentuser to be modified by different browsers, and then the polluted data results contrary to the developer's imagination can be obtained.

Figure 6. Sleep in the problem code segment

click to enlarge

Line 104 of threadsafetyproblem.java is the breakpoint, which uses the polluted results to build page elements.

Figure 7. Breakout point of problem code segment

click to enlarge

Attack scenario

Deploy the webgoat project and start the production environment.

Open two browsers A and B. click "concurrency - thread safety problems" in the left navigation directory.

A browser input user name Jeff, submit;

B browser input user name Dave, fast submission;

It can be seen that the page content of a is updated to the Dave table of B.

Solution

In line 59 of threadsafetyproblem.java, comment out the static variable and change it to the local variable currentuser. The code snippet is as follows:

Figure 8. Code to rectify thread safety

click to enlarge

After the above rectification code compilation and deployment, the attack scenario of webgoat production environment no longer appears.

There are many countermeasures for thread synchronization. According to the application scenario, the following methods are adopted flexibly:

1. First, it is recommended to define variables as local variables rather than global static variables.

2. The Java language itself provides a native support for threads, synchronized. By synchronizing a piece of code or the whole method, it can ensure that only a single thread can execute it at the same time, thus realizing thread safety. Introducing synchronization has a side effect, that is blocking. Developers should try to avoid using synchronization. Whether it's the synchronized keyword or those synchronization classes (hashtable or vector), try to avoid using them.

3. Historically, the isthreadsafe property / singlethreadmodel interface provided by JSP / servlet has been used to solve the thread safety problem of global variables. Singlethreadmodel cannot solve all thread safety problems. Even with singlethreadmodel, session properties can still be accessed by multithreaded requests at the same time. Singlethreadmodel each thread has its own instance, which consumes memory resources. Singlethreadmodel interface is not recommended for servlet API version 2.4.

4. If Java Web uses a framework, thread safety can be achieved by configuring the framework. If the struts 2 framework is used, its default implementation mode is prototype, and an action instance is newly generated for each request, so there is no thread safety problem caused by global variables. If you use not only struts 2, but spring + struts 2. Use spring to manage the actions of struts 2. Note that spring uses the singleton mode by default. You need to change the scope of the spring configuration file to prototype.

Java and JSP code defect resources are not released

In webgoat project, 196 unreleased resources were found by scanning with fortify tool, of which 175 database connection resources were not released and 21 stream file resources were not released.

Generally speaking, the garbage collection mechanism of Java JVM can deal with many resource release problems, but it also brings performance burden and DDoS hidden danger. Therefore, it is recommended that developers actively release resources that are no longer used, rather than relying on the JVM as a whole.

The source code audit found that the statement obtained by the createcontent() method at line 104 of DOS ﹣ login.java was not released explicitly, which resulted in the system resource of getconnection() at line 96 being locked. The code snippet is as follows

Figure 9. Problem code snippet

click to enlarge

Attack scenario: Although webgoat does not have a sample project for resource release vulnerability, it is easy to understand that DDoS denial of service attacks can be carried out through this vulnerability.

Solution

In the finalize () method, explicitly release the statement snippet as follows:

Finally {

if ( null != statement) {

safeClose(statement);}

}

Other code defects: source code scanning can also find dozens of code defects in webgoat project (hundreds of code defects are actually reported, some are cross references), hard coding, weak encryption, etc. Understanding and rectification are straightforward. The space is limited, not listed one by one.

Concluding remarks

This paper is the third part of Java Web project source code security audit practice. It mainly focuses on file path manipulation, system log spoofing, thread security and resource not released, explains the audit logic, and realizes the attack and defense drill with webgoat project. The fourth part of Java Web project source code security audit practice will audit the configuration of production environment deployment. Welcome to read.

© 2023