JSP security problem and its solution suggestion

js| Security | Problem JSP programming language since the launch date, because of its fast, platform-independent, scalable, object-oriented features have been increasingly widely used, more and more manufacturers have developed a variety of support platforms such as IBM's WebSphere, Bea's WebLogic and so on, there are more and more websites starting to put their own platform architecture in the JSP environment.

But the following is a series of security vulnerabilities, such as source code exposure vulnerabilities, remote arbitrary command execution vulnerabilities, and so on, more headaches, with the increasingly widespread use of JSP, security issues are more and more. As of this article, there are as many 二、三十条 (not including undisclosed) vulnerabilities in the public about JSP on the Internet. (Statistical data from http://www.securityfocus.com)

Do not underestimate these problems, imagine that you have worked hard to develop the JSP code is so easy for others to get, more importantly, when the code for your company's website is downloaded, people who have no intention will look at your code and find some loopholes to attack your company's Web site, so these problems cannot be ignored. The author in Sohu search some of the domestic web site with JSP, the results found that some sites do exist a variety of vulnerabilities, you can easily download the JSP source code.

This article focuses on the JSP security issues to classify and propose solutions, so each type of security problem only takes one example, for the details of other vulnerabilities such as what kind of software version of the operating system and so on are not elaborated, interested readers can go to my website JSP enthusiasts (http://jspbbs.yeah.net) or foreign security site (http://www.securityfocus.com) for viewing and reference.

Based on the existing JSP security issues, we may want to divide them into the following categories, source code exposure classes, remote program execution classes and other categories, let's look at the specific things.

First, source code exposure class

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 can cause the source code exposure vulnerabilities, simple examples as long as the program file name after adding a few simple characters can get program code, such as the Common Microsoft ASP global.asa+.htr, xxxx.asp% 81 and so on loopholes.

1, add a special suffix to cause the JSP source code exposure

Problems similar to those in the ASP are also present in the JSP, such as the IBM Websphere application Server 3.0.21, the BEA Systems Weblogic 4.5.1, Tomcat3.1, and other JSP file suffix capitalization vulnerabilities; JSP Furu Resin1.2 with special characters after the file%82 、.. /vulnerabilities, servletexec of%2e, + vulnerabilities, and so on.

Example: An older example of JSP capitalization, Tomcat3.1 in the browser is originally http://localhost:8080/ INDE.JSP, you can normally explain the implementation, 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.

Reason: JSP is case sensitive, Tomcat will only lowercase jsp suffix 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.

Solution: First, on the Server software site download patches; Because I used to use ASP for a period of time, contact with a lot of IIS vulnerabilities, its effective solution is to remove unnecessary mappings such as HTR, HTX and so on, in the JSP we can also refer to the IIS solution, Instead of removing it, you add a mapping by adding some mappings to the server settings such as. Jsp. JSP,. jsp%2e, etc., map them to a written servlet, the only function of this servlet is to direct the request to a custom-like 404 Not Found error page, different server settings are different, please refer to the appropriate documentation. The second solution can be used when there are no patches.

2. Inserting a special string causes the JSP source code to expose

Another is the vulnerability caused by inserting a special string, BEA WebLogic Enterprise 5.1.
The file path starts with a "/file/" vulnerability, IBM WebSphere 3.0.2 "/servlet/file/" file opening vulnerabilities, and so on.

Example: In IBM WebSphere 3.0.2, if the URL of a request file is "login.jsp": http://site.running.websphere/login.jsp, then access http:// Site.running.websphere/servlet/file/login.jsp will see the source code for this file.

Reason: Because IBM WebSphere 3.0.2 is calling 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.

Workaround: Download the latest patches on the Server Software Web site.

3, path permissions caused by the file JSP source code exposure

This vulnerability is not reflected in the normal JSP vulnerability, but the author in the write JSP program has encountered, headaches for a while, finally solved. We know that most JSP applications in the current directory will have a web-inf directory, this directory usually contains JavaBeans compiled class files, if not to the directory to set normal permissions, all class will be exposed.

Example: The author used the Apache1.3.12 plus the Third-party JSP software form of the Web server, because Apache1.3.12 default settings can read the directory, if the program in Http://site.running.websphere/ login.jsp, just modify the http://site.running.websphere/WEB-INF/all of this directory and this directory under the subdirectory of the class file can be seen a full, but also can be downloaded to the computer.

Perhaps you will say class is compiled, even if it is not related to the download, but now class decompile to Java code software is also a lot, the author was using jad software to download the class file decompile, incredibly and the original Java file almost exactly the same, The variable names have not changed, and what is more surprising is that you can recompile the class file for normal use.

Security problem is even greater, the author began to write the database username password in the Java code, now a decompile who can see the important information of the database. Through the remote connection function of the database, it can easily enter into your database, all the information is in his hand. Incidentally, if the user can get SQL Server username password (sa), enter the database can execute arbitrary DOS commands such as view C: file, create and delete directories, etc., so that the entire Windows system is not secure (this method is more harmful, the author is not published).

The author has stumbled on the Internet to see a large web site has the same problem, and the password is written in the same javabean as the author, very unsafe.

Workaround: A previously valid solution for ASP by IIS is to place the ASP program in a separate directory, and the user rights on the directory settings can only be performed unreadable. In the JSP environment can also be set up by setting the server environment to solve this problem, simply put some of the more important directories such as web-inf, classes, such as access to the permissions, not allowed to read and only allowed to execute. 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 stupid solution is to add a default starting page, such as inde.htm, to each important directory, so that reading the directory will return to the visitor's file instead of the other. A recommended method of use.

More important is the password to save the problem, the author of the previous ASP in the development of a password file saved in the system directory such as Winnt, and then wrote a COM to read this file, so even if you see the ASP source code also do 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.

4, the file does not exist caused by absolute path exposure problem

This question is believed that everybody is familiar, because Microsoft IIS also has the quite many similar problems like Microsoft IIS5.0 *.IDC exposes the absolute path flaw. The same issues are now being transferred to the JSP environment, this vulnerability exposes the Web program's absolute hard disk address, and other vulnerabilities combined with a relatively large harm, because this vulnerability is not currently seen on foreign security sites, and the webmaster did not one by one tested all the JSP server program, So there is no way to tell everyone that there is this loophole, you can test on your own Web server to see.

Example: Under a specific server software, access to a non-existent JSP file such as http://localhost:8080/fdasfas.jsp, will return Java.servlet.ServletEception: java.io.filenotfoundeception:c:webappfadssad.jsp (???????????) Such a mistake, so that you can know your site in the C:webapp directory, perhaps the General people do not care, but for a hacker is very helpful.

Reason: This is not filtered out when handling exceptions in the relevant servlet that is responsible for JSP execution.

Solution: First, download the latest patches; Because I did not have the Web server software This patch, after a period of pain, finally found another way, is to find the Server Software JSP implementation mapping servlet file (of course, the class suffix), Jad it with the software, in the back of the source code to find the way to deal with Eception, and then the processing part of the method all commented out, and the request directed to a custom error page, so the problem is solved.

Second, the remote program execution class

Such vulnerabilities are characterized by the use of URL addresses in the browser to execute arbitrary server commands and programs, resulting in security issues. such as Allaire JRUN 2.3 Remote execution of arbitrary command vulnerabilities, IPlanet Web Server 4.x a buffer overflow vulnerability, and so on.

Example: Allaire's JRUN server 2.3, enter the following URL address http://jrun:8000/servlet/jsp/../../path/sample.txt, access to files outside the Web directory, if it is EXE file, may also cause execution.

Reason: If the target file for the URL request uses the prefix "/servlet/", the JSP interpretation execution function is activated. In the target file path requested by the user, use the ".. /, it is possible to access files outside the root directory on the WEB server. Using this vulnerability on the target host to request a file from user input will seriously threaten the security of the target host system.

Workaround: Install the latest patches.

Iii. Other Categories

The scope of these categories is a bit large and can include vulnerabilities such as SQL Server, Oracle, DB2, and so on, as well as operating systems such as windowsnt/2000, Linu, and so on. These loopholes can be said to be fatal, such as the use of Linu some vulnerabilities can easily su for the administrator to remotely control the server, get the full control of the system, so to get the JSP source code or destroy the server than to trample on an ant is much easier.

Iv. Summary of the full text

Through the above we can see that JSP and the same as the ASP still have a lot of security problems, objectively speaking, the server software developers in the internal testing is not possible to find all the bugs in the system, even if the software released, 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.

A good advice is to read more security articles, these security articles will generally have detailed information such as software version number, vulnerabilities, and so on, the most important thing is also included with the solution or a patch download link, The recommended security site is the domestic security site www.cnns.net or foreign www.securityfocus.com site; Another good suggestion is to install multiple patches, visit the company homepage of the software you use, get the latest patches from there, and do a better job of Microsoft's site, security bulletin and Patches are particularly timely.

Finally want to use a sentence as the end of the full text: A good hacker is not necessarily a good JSP programmer, a good JSP programmer must be a good quasi-hacker.