Summary and Analysis on JSP Source Code Leakage

Www.2cto.com: an old article in

Since its launch, JSP programming language has been widely used due to its fast, platform-independent, scalable, and object-oriented features, more and more manufacturers have developed a variety of support platforms, such as IBM WebSphere and BEA's WebLogic. More and more websites have begun to build their own platform architecture in the JSP environment.

However, this is followed by a series of security issues, such as JSP Source Code leaks, remote arbitrary command execution vulnerabilities, and so on. Some JSP-based websites have various vulnerabilities, hackers can easily download the source code of a program, posing a threat to website security.

Causes of JSP Source Code Leakage

Server Vulnerabilities are the origin of security issues, and most of the attacks on websites by hackers start from finding vulnerabilities of the other party. Therefore, website administrators can take appropriate measures to prevent external attacks only by understanding their vulnerabilities.

Although JSP is also a web programming language, it works differently from other web programming languages such as PHP and ASP.

Calling the JSP file for the first time is actually a process of compiling Servlet. Attackers (such as hackers) who attempt to download JSP source code often exploit various vulnerabilities in JSP to send JSP files to the client as a text or other file by the browser before compilation, or when the JSP is loaded, the compiled Servlet is not executed, and the JSP content is directly read and sent to the client, so that the source code can be seen at a glance.

Several types of JSP Source Code Leakage

The source code exposure category mainly refers to that the program source code will be returned to visitors in plaintext.

We know that dynamic programs, such as JSP, ASP, and PHP, are executed on the server. After execution, they only return standard html and other code to visitors. This is a theoretical thing. In practice, the internal mechanism of the server may cause the vulnerability of source code exposure, in a simple example, you can add a few simple characters after the program file name to obtain the program code, such as the common Microsoft ASP global. asa +. htr, XXXX. vulnerabilities such as asp % 81.

1. JSP Source Code leakage caused by adding special suffixes

JSP also has issues similar to asp vulnerabilities, such as IBM Websphere Application Server 3.0.21, BEA Systems Weblogic 4.5.1, and Tomcat; add special characters such as % 82 and .. Of Resin1.2 to the JSP file ,.. /vulnerabilities; % 2E, +, % 2E, +, % 2B, % 5C, % 20, and % 00 of ServletExec.

Hackers exploit this vulnerability to leak the source code of the specified JSP file. Example 1: use any of the following URL requests to output the source code of the specified JSP file:

1) http: // target/directory/jsp/file. jsp.

2) http: // target/directory/jsp/file. jsp % 2E

3) http: // target/directory/jsp/file. jsp

4) http: // target/directory/jsp/file. jsp % 2B

5) http: // target/directory/jsp/file. jsp

6) http: // target/directory/jsp/file. jsp % 5C

7) http: // target/directory/jsp/file. jsp % 20

And so on.

Example 2: In Tomcat, http: // localhost: 8080/inde can be normally interpreted in the browser. jsp, but if the inde. change jsp to inde. JSP or inde. jsp and so on. You will find that the browser will prompt you to download this file. After downloading the source code, you can check the source code.

The reason is that JSP is case sensitive. Tomcat will only execute the file with the lower-case JSP suffix as a normal JSP file. If it is capitalized, it will cause Tomcat to change the value of inde. JSP is a downloadable file for customers to download. Earlier versions of WebLogic and WebShpere all have this problem. Now these companies have released new versions or patches to solve this problem.

Solution

There are two ways to solve the source code leakage caused by adding a suffix. One is to download the patch on the website of the server software; another method is to add some mappings in the server settings, such. JSP ,. jsp ,. jsp % 2E and so on, map them to a self-written servlet, the only function of this Servlet is to direct the request to a custom error page similar to 404 not found, different server settings are also different.

If no static page or image is used, you can configure a default servlet and map "/" to this default servlet. In this way, when a URL not mapped to a servlet is received, the default servlet will be called. In this case, the default servlet can only return "files not found ". If a static page or image is used, you can still configure it like this, but you need to have this default servlet process requests for valid static pages and images.

Another possibility is to map *. jsp +, *. jsp. And *. jsp to a servlet, And the servlet only returns "file not found ". For situations such as *. jsp % 00 and *. jsp % 20, the ing should be input without encoding. For example, for *. jsp % 20 ing, enter "*. jsp ". Note that % 20 is converted into a space character.

Ii. inserting special strings causes JSP Source Code Leakage

There are many vulnerabilities caused by inserting special strings, such as in BEA WebLogic Enterprise 5.1, the file path starts with "/file/" and the file/servlet/file/in IBM WebSphere 3.0.2.

If the URL of a request file in IBM WebSphere 3.0.2 is "login. jsp": runtime, the source code of this file is displayed.

This is because IBM WebSphere 3.0.2 calls different servlets to process different pages. If a requested file is not registered for management, WebSphere uses a default servlet call. If the file path starts with "/servlet/file/", the default servlet will be called by the requested file and will be displayed without analysis or compilation.

Solution

Download the latest patch from the server software website.

Iii. File JSP Source Code leakage caused by path Permissions

This vulnerability is not reflected in the normal JSP vulnerability, but we know that most JSP applications in the current directory will have a WEB-INF directory, this directory usually stores the class files compiled by JavaBeans. If you do not set normal permissions for this directory, all the classes will be exposed.

Some people may think that the class is compiled, and it does not matter even if it is downloaded. But now there are a lot of software that decompile the class into java code. After the decompilation software is used to decompile the downloaded class file, it is almost the same as the original java file. Even the variable name is not changed and can be used normally.

The bigger security problem is that some software developers write all the username and password of the database in java code. Now, anyone who decompile the database can see the important information of the database. Through the remote connection function of the database, you can easily access the database, and all the information will be mastered by others.

Solution

One method can effectively solve the code leakage problem caused by path permissions. It is to place the ASP program in a separate directory and set the user permissions on the directory to be read only. In the JSP environment, you can also set the server environment to solve this problem: Set access permissions for important directories such as WEB-INF and classes, read is not allowed and only execution is allowed. Take Apache solution as an example, you can add a directory WEB-INF In the httpd. conf file and set attributes such as Deny from all.

Another solution is to upload a starting page such as index.htm in each important directory, so that the directory will be read and the file will be returned to the visitor instead of the other.

In comparison, we recommend that you use the first method.

More importantly, the password is saved. In ASP development, you can save the password file in a system directory such as WINNT and then use a com to read the file, in this way, even if you see the ASP source code, you do not know the database information. In JSP, we can also write a property file, place it in the WINNT system directory, and then use Bean to read the database information, so that the source code knows that the database information exists in WINNT. property file, but it is difficult to access it, so that even if the source code is known, at least the database is safe.

Iv. absolute path JSP Source Code leakage caused by non-existent files

This problem has already occurred many times, because Microsoft IIS also has many similar problems, such as the absolute path vulnerability exposed by *. idc in Microsoft IIS5.0. These same problems are now occurring in the JSP environment. This vulnerability exposes the absolute hard disk address of the web program, which can be combined with other vulnerabilities to cause great harm.

For example, access a non-existent JSP file under a specific server software, such Will return Java. servlet. ServletEception: java. io. FileNotFoundEception: c: webappfadssad. jsp (???????????)If this error occurs, you may know that your website is under the c: webapp directory, but it is sufficient for a hacker.

This is because the exception is not filtered out when the Servlet responsible for JSP execution handles exceptions.

Solution

There are two solutions to the absolute path exposure problem caused by the absence of files. One way is to download the latest patch. Another method is to find the JSP execution Servlet ing Servlet File of the server software (of course the class suffix), decompile it with the software, and find the method to process Eception in the decompiled source code, then, comment out the processing part of the method and direct the request to a custom error page. This solves the problem.

Conclusion

We can see from the above content that there are many security JSP Source Code leaks. Objectively speaking, server software developers cannot find all the bugs in the system during internal testing, even after the software is released, the discovered JSP Source Code leakage will only be a small part of it, and new security problems will emerge in the future. Therefore, we must always be vigilant, pay attention to the security of your website