Source code leakage problem in JSP-vulnerability research

Absrtact: While JSP technology has been widely used, the JSP security caused by source code leakage has been widely concerned. In this paper, several factors that cause source code leakage are analyzed, and the solutions to each of these factors are presented.
Tags: JSP source code leaks
Introduction
JSP programming language Since the launch date, because of its fast, platform-independent, scalable, object-oriented features have been more and more widely used, more and more manufacturers have developed a variety of support platforms such as IBM's WebSphere, BEA Company's WebLogic and so on, There are more and more websites that are starting to put their own platform architecture in the JSP environment.
But then comes a series of security issues, such as source code exposure vulnerabilities, remote arbitrary command execution vulnerabilities, and so on, some use JSP to do the site, because there are a wide range of loopholes, hackers can easily download the source code of the program, the security of the site poses a threat.
Causes the JSP source code to expose
The server vulnerability is the origin of security problems, the hacker attacks on the site are mostly from the search for each other's vulnerabilities began. Therefore, only by understanding their own vulnerabilities, site managers can take appropriate countermeasures to prevent foreign attacks.
Although JSP is a kind of web programming language, it is different from other Web programming languages such as PHP and ASP's working mechanism.
The first call to the JSP file is actually a process that compiles to a servlet. Attempts to download JSP source code (such as hackers) often use the various vulnerabilities of JSP, so that the JSP file before compiling by the browser as a text or other files sent to the client, or in the JSP load when not to perform a compiled servlet and directly read the contents of the JSP and send to the client, So that the source code at a glance.
Several types of JSP source code leaks
The source code exposure category refers primarily to the way the program source code is returned to the visitor in clear text.
We know whether JSP or ASP, PHP and other dynamic programs are executed on the server side, the implementation will only return to the visitor standard HTML code. This is a theoretical thing, actually running because of the internal mechanism of the server is likely to cause the source code exposure vulnerability, a simple example is a few simple characters after the program file name can get the program code, such as the Common Microsoft ASP global.asa+.htr, xxxx.asp% 81 and so on loopholes.
3.1 Adding a special suffix causes the JSP source code to expose
In JSP, there are also problems similar to those of ASP, such as IBM Websphere application Server 3.0.21, BEA Systems Weblogic 4.5.1, Tomcat3.1, and other JSP file suffix capitalization vulnerabilities; JSP files Add special characters Furu Resin1.2%82 、.. /vulnerabilities, servletexec%2e, + vulnerabilities,%2e, +,%2b,%5c,%20,%00, etc.
If the hacker exploits this vulnerability, it will cause the source code of the specified JSP file to be compromised. Example: Use any of the following URLs to request that the source code for the specified JSP file be output:
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
8) http://target/directory/jsp/file.jsp%00
Wait a minute.
Example two, under the Tomcat3.1, in the browser can normally explain the execution is http://localhost:8080/ inde.jsp, but if the inde.jsp changed to inde.jsp or inde.jsp wait and see, you will find that the browser will prompt you to download the file, download the source code can be seen.
The reason is that the JSP is case-sensitive, Tomcat will only use the lowercase jsp suffix of the file as a normal JSP file to execute, if uppercase will cause Tomcat will inde.jsp as a downloadable file for customers to download. This is the problem with older versions of WebLogic, Webshpere, and so on, and now these companies have either released a new version or released patches to solve the problem.
3.1.1 Solutions
There are two ways to resolve this source code leak due to the addition of suffixes, one way is to download patches on the Web site of the server software, and another way to add some mappings to the server settings such as. Jsp. JSP,. jsp%2e, and so on, mapping them to a servlet of their own writing, the only function of the servlet is to redirect the request to a custom error page similar to 404 Not Found, where different server settings are different.
If you do not use any static pages or images, you can configure a default servlet and map "/" to this default servlet. This default servlet is invoked when a URL that is not mapped to a servlet is received. In this case, the default servlet can simply return "files not found". If you use a static page or image, you can still make such a configuration, but you need to have this default servlet handle requests for legitimate static pages and images.
Another possibility is to map *.jsp+, *.jsp. and *.jsp\ to a servlet that simply returns "files not found." For cases such as *.jsp%00 and *.jsp%20, mappings should be entered in an encoded form. For example, you should enter "*.jsp" for *.jsp%20 mappings. Note that the%20 is converted to a space character.
3. 2 inserting a special string causes the JSP source code to expose
There are a number of vulnerabilities that can be caused by inserting a special string, such as the "/file/" vulnerability at the start of the file path, the "/servlet/file/" file opening vulnerability in IBM WebSphere 3.0.2, and so on, in Bea WebLogic Enterprise 5.1.
If the URL of a request file in the IBM WebSphere 3.0.2 is "login.jsp": http://site.running.websphere/login.jsp, then the user accesses the http:// Site.running.websphere/servlet/file/login.jsp will see the source code for this file.
The reason is that because IBM WebSphere 3.0.2 calls different servlets to handle different pages, WebSphere uses a default servlet call if a requested file is not registered for administration. If the file path starts with "/servlet/file/" the default servlet will be invoked this requested file will be displayed without parsing or compiling.
3.2.1 Resolution Method
Download the latest patches on the Server Software Web site.
3.3 path permissions caused by file JSP source code exposure
This vulnerability is not reflected in normal JSP vulnerabilities, but we know that most JSP applications have a web-inf directory in the current directory, which usually contains JavaBeans compiled class files, and if you do not set normal permissions on this directory, All class will be exposed.
Perhaps some people think that class is compiled, even if the download is not what the relationship, but now class decompile to Java code software is also a lot of, using the decompile software to download the class file decompile, and the original Java file almost exactly the same, even the variable names have not changed, can also be used normally.
A bigger security issue is that some software developers write the database's username and password in Java code, and now anyone who can read the database has important information. Through the remote connection function of the database, it can easily enter into the database, all the information will be mastered by others.
3.3.1 Resolution Method
There is a way to effectively solve the problem of code leakage due to path permissions, that is, to place the ASP program in a separate directory, set the user permissions on the directory can only perform unreadable. In the JSP environment can also be set up by setting the server environment to solve this problem: some of the more important directories such as Web-inf, classes, and other settings to access the permissions, not allowed to read and only allow execution. In the case of Apache workaround, you can add a directory Web-inf to the httpd.conf file and set the Deny from all attribute.
Another solution is to add a default start page, such as index.htm, to each important directory, so that reading the directory returns to the visitor's file instead of the other.
By comparison, the first method is recommended.
More important is the password to save the problem, in the development of ASP, you can save the password file in the system directory such as Winnt, and then use a COM to read the file, so that even if you see the ASP source code does not know the database information. In the JSP we can also write a property file, placed in the Winnt system directory, and then use the bean to read the database information, This way through the source code to know that the database information exists in the Winnt in the. property file, but also difficult to access it, so even if the source code is known that the minimum database is safe.
3.4 The absolute path exposure problem caused by the absence of files
This problem has now appeared a lot, because Microsoft IIS also has a number of similar problems, such as Microsoft IIS5.0 in the *.IDC exposure absolute path vulnerability. The same problems now appear in the JSP environment, which exposes the absolute hard disk address of the Web program, and the combination of other vulnerabilities can be quite damaging.
For example: Under a specific server software, access to a non-existent JSP file such as The reason is that this is not filtered out because the exception is handled in the relevant servlet that is responsible for JSP execution.
3.4.1 Resolution Method
There are two solutions to the problem of absolute path exposure due to file absence. One way is to download the latest patches. Another method is to find the Server Software JSP execution mapping servlet file (of course, the class suffix), will it with the software decompile, in the back-compiled source code to find a way to deal with Eception, and then the processing part of the method all commented out, and directs the request to a custom error page, which solves the problem.
Conclusion
As we can see from the above, JSP still has a lot of security problems, objectively speaking, the server software developers in the internal test is not possible to find all the bugs in the system, even after the release of software, the discovered vulnerability will only be a small part of it, There will be new security problems in the future, so we must always be vigilant and pay attention to the safety of our website.


Reference documents
Bergsten, "JSP design", China electric Power Press
Http://www.99net.net
Http://www.mhdn.net