First, the source code is exposed. Adding a special tail code causes JSP source code Exposure to the JSP and similar problems with these vulnerabilities in the JSP, such as IBM WebSphere Application Server 3.0.21, Bea Systems Weblogic 4.5.1, Tomcat3.1, etc. JSP file tail code uppercase vulnerabilities; The JSP file is added to the special character such as RESIN1.2% 82, .. / vulnerability,% 2e, vulnerability, etc. of servletexec. Example: Lifting an older JSP case, Tomcat3.1 is originally http: // localhost: 8080 / inde.jsp, can be explained normally, but if inde.jsp is changed to inde.jsp or INDE.JSP, etc., you will find that the browser will prompt you to download this file, download the back source code to see a dry two. Cause: JSP is sensitive, Tomcat will only perform the files of the lowercase JSP tail code as a normal JSP file. If the uppercase will cause Tomcat to make Index.jsp as a file that can be downloaded. Customer download. The old version of WebLogic, WebShpere has existed this problem, and now these companies have a new version or release the patch to solve this problem. Workaround: First, download patch on the server's website; We can also refer to IIS's solution, different is to remove but add mappings, the method is to add some mappings such as .jsp, .jsp, .jsp% 2E, etc. in the server settings, map them to a write Servlet, the only function of this servlet is to guide the request to a custom page error page, different server settings, please refer to the appropriate document. The second solution can be adopted when there is no patch. 2. Inserting a special string causes the JSP source code to expose a vulnerability caused by the inserted special string, the BEA WebLogic Enterprise 5.1 file path is "/ file /" vulnerability, IBM WebSphere 3.0.2 "/ servlet / file /" File opening vulnerability, etc. Example: If IBM WebSphere 3.0.2, if a 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. Cause: Because IBM WebSphere 3.0.2 is to call different servlets to handle different pages. If a request file is not registered, WebSphere will use a default servlet call. If the file path will begin with "/ servlet / file /" This default servlet will be called this request file that will be displayed or compiled. Workaround: Download the latest patches in the website of the server software. 3. The file JSP source code exposed to the path permission. We know that most of the JSP applications have a web-inf directory in the current directory. This directory is usually stored in the Class file compiled by JavaBeans. If you do not give this directory setting Normal permissions, all CLASs will be exposed.
Example: If an apache1.3.12 is used, a web server in a third-party JSP software is applied, because Apache 1.3.12 The default setting is to read the directory, if the program is http: //site.running.Websphere/login. JSP, just modify http: //site.running.Websphere/web-inf / all this directory and the Class file in the subdirectory in this directory can be seen, you can also download it to this unit. Maybe someone will say that Class is compiled, even if there is nothing to download by people, now there is a lot of software that Class's anti-compile to Java code. Some people have compiled the downloaded Class files, actually and original The Java file is almost exactly, and the variable name has not changed, more amazing is to recompile to the Class file normally used. The security problem is greater, and the web producer began writing the username password of the database in Java code. Now it is important information about the database. Through the remote connection function of the database, you can easily enter your database, all the information is in his hands. Incidentally, if the user gets the username password of SQL Server, enter the database can perform any DOS commands such as viewing C: / files, establish and delete directory, etc., the entire Windows system is not safe. Workaround: IIS previously effectively solves the ASP vulnerability, that is, put the ASP program separately a directory, the user permissions on the directory setting can only be read. In the JSP environment, you can also solve this problem by setting the server, simply, is to access some of the more important directories such as Web-INF, CLASSES, etc., not allowed to read only the permission . Solve in apache as an example, you can add a directory web-infront in the httpd.conf file and set attributes such as Deny from ALL. Another stupid solution is to add a default start page such as Index.htm in each important directory, so that the read directory will return to the visitor's file instead of other. It is recommended to adopt. More importantly, the password is saved. You can write a Property file in the JSP, place it in the Winnt system directory, then use bean to read the database information, so that the library information exists in Winnt .property files in WinNT, it is difficult Access it, so that the source code is secured by the person to the code library is safe. 4. The absolute path exposure problem caused by the document is believed to be familiar with everyone, because there are more similar problems in Microsoft IIS. Such as the * .idc exposed absolute path vulnerability in Microsoft IIS5.0. The same these problems are now also transferred to the JSP environment. This vulnerability exposes the absolute hard drive address of the Web program, and other vulnerabilities have a relatively large harm: under a specific servo software, access one does not exist JSP files such as http: // localhost: 8080 / fdasfas.jsp, will return java.servlet.servleteption: java.io.filenotFoundeception: c: /web/app/fadssad.jsp (???????? ???) This error, you can know that the website is in the C: / Web / App directory, perhaps the average person is not intended, but it is very helpful for a hacker. Cause: There is no filtering when the abnormality is handled in the relevant servlets executed by JSP.
