JSP Vulnerabilities Great

JS One, source code exposure types

1. Adding special tails causes JSP source code to be exposed to JSP there are also vulnerabilities such as ASP, such as IBM Websphere application Server 3.0.21, BEA Systems Weblogic 4.5.1, Tomcat3.1, such as JSP file Tail code large write vulnerability; JSP file with special characters such as Resin1.2%82 、.. /vulnerabilities, servletexec of%2e, + vulnerabilities, and so on.
Example: An older JSP big-write example, Tomcat3.1 in the browser is http://localhost:8080/inde.jsp, can be normally explained, but if the inde.jsp to inde.jsp or inde.jsp wait and see, you'll notice that the browser will prompt you to download this file and download the source code to see a clean one.
Reason: JSP is case-sensitive, Tomcat will only write the small JSP tail file as a normal JSP file to execute, if the big write would lead to Tomcat index. JSP is a download-capable file that downloads the customer. Older versions of WebLogic, Webshpere and so on have this problem, and now these companies either have a new version or a patch to solve the problem.
Solution: One is to download the top of the Server Software Web site; Because the author has used ASP for some time, contact 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 reference the IIS solution method, Instead of removing it, you add the mappings by adding some mappings to the server settings such as. Jsp. JSP,. jsp%2e, and so on, map them to a servlet that you wrote, the only function of this servlet is to ask for the wrong page of a custom-like 404 Not Found, where different server settings are different, please refer to the document file. The second solution can be used without a patch.
2. Inserting a special string causes JSP source to be exposed
Another is the vulnerability caused by inserting a special string, and the BEA WebLogic Enterprise 5.1 file path starts with a "/file/" vulnerability, an IBM WebSphere 3.0.2 "/servlet/file/" file opening vulnerability, and so on.
Example: In IBM WebSphere 3.0.2, if a request for a file URL is "login.jsp": http://site.running.websphere/login.jsp, then visit http:// Site.running.websphere/servlet/file/login.jsp will see the source code for this file.
Why: Because IBM WebSphere 3.0.2 is a different servlets for different pages, if a request file is not registered for administration, WebSphere uses an implied servlet to tune it up. \ \ \ If the file path is opened with "/servlet/file/" This implied servlet will be tuned to this request file is displayed without being parsed or translated.
Solution: Download the latest patches from the server Software's Web site.
3. Path may be caused by file JSP source code exposure
We know that most JSP applications will have a web-inf in front of the record, which usually contains the class file after JavaBeans, and all classes will be exposed if you do not set the normal permissions for this document to be stored.
Example: If you are using a Web server in the form of Apache1.3.12 plus third-party JSP software, because Apache1.3.12 settings are available for reading, if the program is http://site.running.websphere/ login.jsp, just change the http://site.running.websphere/web-inf/all the class files in this catalogue and in this catalogue can be viewed as a clean, and can be downloaded to the machine.
Maybe some people say that class is translated, and that it doesn't matter if it's being downloaded, but there are also a lot of software in the Java code, and someone has used jad software to translate the downloaded class file, almost as much as the original Java file, The variable names don't change, and what's even more surprising is that you can also rearrange the normal use of class files.
The bigger security issue is that the Web Author started to write the user code for the library in Java code, and now anyone who can see the important information in the library is a translator. Remote connectivity through the data library can be easily entered into your library, all of the information is in his hands. Incidentally, if the user can obtain SQL server username password, access to the library can execute arbitrary DOS commands such as view C:\ file, create and delete the catalogue, so that the entire Windows system is not safe.
Workaround: One of the ways in which IIS used to effectively resolve ASP vulnerabilities is to place an ASP program on its own, and the user can only perform an inability to read. In the JSP environment, you can solve this problem by setting the server's environment, simply put, you can access some of the more important items such as web-inf, classes, and so on, and then just allow them to be allowed to read. In Apache, for example, you can add a web-inf to the httpd.conf file and set deny from all.
Another way to solve this problem is to add a default starting page such as index.htm in each important catalogue, and the reading will return to the interview file instead of the other one. " A method of advice.
What's more important is the problem of keeping passwords. You can write a property file in a JSP, place it in the Winnt system, and then use the bean to read the library information, so that the source code knows that the. property file in the Winnt exists in the library information. 堶 Love A but also very difficult to interview it, This way, even if the source code is known to be safe for the data library.
4. The absolute path exposure caused by a file does not exist. This question is more familiar to everyone, because there are also a lot of similar problems in Microsoft IIS. such as the *.IDC in the Microsoft IIS5.0 exposes the path vulnerability. The same problems are now being transferred to the JSP environment, which exposes the Web program's absolute hard disk address, which is more damaging than the other vulnerabilities.
Example: Under a particular server software, a non-existent JSP file, such as http://localhost:8080/fdasfas.jsp, returns Java.servlet.ServletEception: java.io.filenotfoundeception:c:\web\app\fadssad.jsp (???????????) Such a mistake, you can know that the Web site in the C:\web\app, and perhaps the general people do not care, but for a hacker to say is very helpful.
Reason: The relational servlet that is responsible for JSP does not filter out this situation when it is in the process of being handled in a different way.
Solution: One is to download the latest patches; If the Web server software does not have this patch, you can find the Server Software's JSP executable map servlet file (which is, of course, the class tail), and use it jad software to translate it, Find a way to handle the exception in the source code after the translation, and then remove all of the processing from the method, and then ask for a custom error, and the problem is solved, "he explained."

Two, remote program to perform the type

The special point of this vulnerability is that it can be used to perform commands and programs on any server in the browser via URL addresses, causing security problems. such as Allaire JRUN 2.3 Remote Execution Arbitrary command vulnerabilities, IPlanet Web Server 4.x a buffer overflow vulnerability, and so on.

Example: Allaire's JRUN server 2.3 input the following URL address Http://jrun:8000/servlet/jsp/../../path/sample.txt, you can access to the Web document other than the file, if it is EXE file, it may also cause the execute.

Cause: If the URL asks for the target file using the word "/servlet/", then the JSP explain the function is enabled. This is used in the use of the target file path in the user request. /, you may be able to interview files that are not in the root of the WEB server. Use this vulnerability on the target host to request a user to enter a file that will seriously threaten the safety of the target host system.

Solution: Install the latest patches.

The reason for this old post is that it says that Tomcat 5.0.19 windows also writes out the source code, and interesting friends try to see if that's true, and the Tomcat guy has fallen in the old place again. "