JSP vulnerability Overview

Summary: Server Vulnerabilities are the origin of security issues, and most of the attacks by hackers against websites begin with finding vulnerabilities of the other party. Therefore, website administrators can take appropriate measures to prevent external attacks only by understanding their vulnerabilities. The following describes common vulnerabilities on some servers (including web servers and JSP servers.

What is the vulnerability in Apache that exposes and overwrites arbitrary files?

There is a mod_rewrite module in apache1.2 and later versions, which is used to specify the absolute path mapped by the special URLs on the Network Server File System. If an rewrite rule containing correct parameters is transmitted, attackers can view arbitrary files on the target host.

The following is an example of rewriting rule commands (the first line only contains vulnerabilities ):

Rewriterule/test/(. *)/usr/local/data/test-stuff/$1
Rewriterule/more-icons/(. *)/icons/$1
Rewriterule/go/(. *) http://www.apacheweek.com/#1

Affected Systems:

1) Apache 1.3.12
2) Apache 1.3.11win32
3) Apache 1.2.x

Unaffected systems: Apache 1.3.13

How to expose JSP by adding special characters to HTTP requestsSource codeFile?
Unify ewave ServletExec is a Java/Java Servlet Engine plug-in for Web servers, such as Microsoft IIS, Apache, and Netscape Enterprise Servers.
When one of the following characters is added to an HTTP request, ServletExec returns the JSP SourceCodeFile.
.

% 2e
+
% 2B
\
% 5c
% 20
% 00

Successful exploitation of this vulnerability will result in leakage of the source code of the specified JSP file. For example, you can 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
8) http: // target/directory/JSP/file. jsp % 00

Affected Systems:

1) Unify ewave ServletExec 3.0c
2) Sun Solaris 8.0
3) Microsoft Windows 98
4) Microsoft Windows NT 4.0
5) Microsoft Windows NT 2000
6) Linux kernel 2.3.x
7) ibm aix 4.3.2
8) HP HP-UX 11.4

Solution:

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, which 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.

What are Tomcat vulnerabilities?

Tomcat 3.1 exposed website Path Problems

Tomcat 3.1 is a software developed in the Apache software environment that supports JSP 1.1 and servlets 2.2. It has a security problem. When a non-existent jsp request is sent, the full path of the web page on the website is exposed.

Example:
Http://narco.guerrilla.sucks.co: 8080/anything. jsp

Result:
Error: 404
Location:/anything. jsp
JSP file "/javasrv2/Jakarta-Tomcat/webapps/root/anything. jsp" not found

Solution: upgrade to the latest version.

Tomcat exposes JSP file content

Java Server Pages (JSP) files are '. JSP 'The extension is registered on Tomcat. Tomcat is case sensitive to file names ,'. JSP 'and '. JSPs are different types of file extensions. If you submit a link with '. jsp' to Tomcat, and tomcat cannot find '. jsp', it will respond to the request with the default '. text' file type. In the NT System, large and lowercase file names are non-sensitive, so the requested file will be sent as text.

If the error message "file not found" is displayed on the Unix server.

How to Implement code protection for tomcat in Windows

Some versions of Tomcat have the source code leakage vulnerability. If you change the file suffix to uppercase when calling the JSP page in a browser, the source code of this JSP file will be completely output to the browser (maybe there is nothing in the browser window, you only need to view the HTML source file to find it ). In this way, will the source code of the website be exposed on the Internet?
Don't worry. The solution is simple. Write all the combinations of various suffixes to atat_home \ conf \ Web. in XML, Tomcat will treat JSP with different extension names separately, and the code will not be leaked.

JSP
*. Jsp

JSP
*. Jsp

? Lt; servlet-Name> JSP
*. Jsp

JSP
*. Jsp

JSP
*. Jsp

JSP
*. Jsp

JSP
*. Jsp

JSP
*. Jsp

What are the allair JRun vulnerabilities?

Illegal WEB-INF read vulnerability in allair JRun
A serious security vulnerability exists in Allaire JRun server 2.3. It allows an attacker to view the WEB-INF directory on the JRun 3.0 server.
If a user makes a URL malformed by appending a "/" when submitting a URL request, all subdirectories under the WEB-INF will be exposed. Attackers can exploit this vulnerability to gain remote access to all files in the WEB-INF directory of the target host system.
For example, using the following URL exposes all files under the WEB-INF:
Http://site.running.jrun: 8100 // WEB-INF/

Affected System: Allaire JRun 3.0

Solution: Download and install the patch:

Allaire patch jr233p_asb00_28_29
Http://download.allaire.com/jrun/jr233p_ASB00_28_29.zip
Windows 95/98/NT/2000 and Windows NT alpha
Allaire patch jr233p_asb00_28_29tar
Http://download.allaire.com/jrun/jr233p_ASB00_28_29.tar.gz
Unix/Linux patch-GNU Gzip/tar

Allaire JRun 2.3 Arbitrary File Viewing Vulnerability

The JRun server 2.3 of Allaire has the multiple display code vulnerability. This vulnerability allows attackers to view the source code of arbitrary files in the root directory on the Web server.
JRun 2.3 uses Java Servlets to parse various types of pages (such as HTML and JSP ). Based on the File Settings of rules. properties and servlets. properties, you may use the URL prefix "/servlet/" to call any servlet.
It may use the SSIFilter servlet of JRun to retrieve arbitrary files on the target system. The following two examples show the URLs that can be used to retrieve arbitrary files:

Http: // JRun: 8000/servlet/COM. livesoftware. jrun. plugins. ssi. SSIFilter/.../../t est. jsp
Http: // JRun: 8000/servlet/COM. livesoftware. JRun. plugins. SSI. SSIFilter /.. /.. /.. /.. /.. /.. /.. /boot. ini
Http: // JRun: 8000/servlet/COM. livesoftware. JRun. plugins. SSI. SSIFilter /.. /.. /.. /.. /.. /.. /.. /winnt/repair/SAM
Http: // JRun: 8000/servlet/SSIFilter/.../../test. jsp
Http: // JRun: 8000/servlet/SSIFilter/.../../boot. ini
Http: // JRun: 8000/servlet/SSIFilter/.../../winnt/repair/SAM ._

Note: Assume that JRun runs on the host "JRun" and port 8000.

Affected System: Allaire JRun 2.3.x

Solution: Download and install the patch:

Allaire patch jr233p_asb00_28_29
Http://download.allaire.com/jrun/jr233p_ASB00_28_29.zip
Windows 95/98/NT/2000 and Windows NT alpha
Allaire patch jr233p_asb00_28_29tar
Http://download.allaire.com/jrun/jr233p_ASB00_28_29.tar.gz
Unix/Linux patch-GNU Gzip/tar

Allaire JRun 2.3 Remote Command Execution Vulnerability

Allaire's JRun server 2.3 has a security vulnerability that allows remote users to compile/execute arbitrary files on the web server as JSP code. If the target file of the URL request uses the prefix "/servlet/", the JSP interpretation execution function is activated. When "../" is used in the target file path requested by the user, it is possible to access files other than the root directory on the Web server. Using this vulnerability to request a file generated by the user input on the target host will seriously threaten the security of the target host system.

For example:

Http: // JRun: 8000/servlet/COM. livesoftware. jrun. plugins. jsp. jsp/.../../path/to/temp.txt
Http: // JRun: 8000/servlet/JSP/.../../path/to/temp.txt

Affected System: Allaire JRun 2.3.x

Solution: Download and install the patch:

Allaire patch jr233p_asb00_28_29
Http://download.allaire.com/jrun/jr233p_ASB00_28_29.zip
Windows 95/98/NT/2000 and Windows NT alpha
Allaire patch jr233p_asb00_28_29tar
Http://download.allaire.com/jrun/jr233p_ASB00_28_29.tar.gz
Unix/Linux patch-GNU Gzip/tar

JRun 2.3.x sample file exposes site security information

JRun 2.3.x contains some servlet sample files in the jrun_home/Servlets directory. This directory is JRun 2.3.x used to load and execute the servlets files. All files with the extension ". Java" or "class" must be deleted because these files expose the Security Information of the site. For example:
The http://www.xxx.xxx/servlet/SessionServlet exposes the HTTP connection information maintained by the current server. Contents in the jrun_home/jsm-default/services/JWS/htdocs Directory should also be deleted. This directory stores the '. jsp' file that demonstrates the server function. Some of the files involve accessing the Server File System and exposing server settings. For example, the path check for the file "viewsource. jsp" is disabled by default and can be used to access the file system on the server.

Solution:

1) install 2.3.3 Service Pack
2) Delete all instruction documents, demo codes, examples, and teaching materials from the server, including the documents stored in the jrun_home/Servlets directory and jrun_home/jsm-default/services/JWS/htdocs directory when JRun 2.3.x is installed.
Related Sites: http://www.allaire.com/

What are the vulnerabilities of IBM WebSphere Application Server?

1. IBM WebSphere Application Server 3.0.2 exposed Source Code Vulnerability
IBM WebSphere Application Server allows attackers to view all files above the Web server root directory. IBM WebSphere uses Java Servlets to Process Analysis of Multiple page types (such as HTML, JSP, JHTML, and so on ). In addition different servlets processes different pages. If a requested file is not registered and managed, WebSphere uses a default servlet for calling. 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.

Affected Systems: All versions of IBM WebSphere 3.0.2

Example:

If the URL of a request file is "login. jsp": http://site.running.websphere/login.jsp.
Solution: download and install patches
Http://www-4.ibm.com/software/webservers/appserv/efix.html
Site: http://www-4.ibm.com/software/webservers/appserv/
IBM WebSphere Application Server exposes JSP file content
Java Server Pages (JSP) files are '. JSP 'The extension is registered on websphere application serve. Websphere is case sensitive to file names ,'. JSP 'and '. JSPs are different types of file extensions. If you submit a link with '. jsp' to websphere, and WebSphere cannot find'. jsp', it will respond to the request with the default '. text' file type. In the NT System, large and lowercase file names are non-sensitive, so the requested file will be sent as text.

If the error message "file not found" is displayed on the Unix server.

Solution: Click here to download the patch
Site: http://www-4.ibm.com/software/webservers/appserv/efix.html
What are the source code vulnerabilities exposed by BEA WebLogic?

Affected Versions:

All systems

BEA WebLogic Enterprise 5.1.x
BEA WebLogic Server and express 5.1.x
BEA WebLogic Server and express 4.5.x
BEA WebLogic Server and express 4.0.x
BEA WebLogic Server and Express 3.1.8

This vulnerability allows attackers to read the source code of all files in the web directory.

WebLogic depends on four major Java Servlets to serve different types of files. These servlets are:

1) fileservlet-for simple HTML page
2) SSIServlet-for server side nodes page
3) pagecompileservlet-for JHTML page
4) jspservlet-for Java Server Page

Looking at the weblogic. properties file, here is the registration value of each servlets:

1) weblogic. httpd. Register. File = weblogic. servlet. fileservlet
2) weblogic. httpd. Register. *. shtml = weblogic. servlet. serversidemo-deservlet
3) weblogic. httpd. Register. *. jhtml = weblogic. servlet. jhtmlc. pagecompileservlet
4) weblogic. httpd. Register. *. jsp = weblogic. servlet. jspservlet
For more weblogic. properties files, if a request file is not registered for management, a default servlet will be called. The following shows how the default servlet is registered.

# Default servlet Registration
#------------------------------------------------
# Virtual name of the default servlet if no matching Servlet
# Is found weblogic. httpd. DefaultServlet = File

Therefore, if the file path in the URL starts with "/file/", WebLogic will call the default servlet, which will directly display the webpage without analysis and compilation.

Argument:

If you add "/file/" to the original URL path of the file you want to view, the file will be directly exposed without analysis and compilation. For example: http://site.running.weblogic/login.jsp, the contents of the file will be seen in the Web browser as long as you access the http://site.running.weblogic/file/login.jsp.

Use the following methods:

1. Force SSIServlet to view unanalyzed pages:
The server site uses the SSIServlet processing page in weblogic. It registers the following information in the weblogic. properties file: weblogic. httpd. Register. *. shtml = weblogic. servlet. serversidemo-deservlet

Use SSIServlet to automatically process wildcards (*) through URLs (*). Therefore, if the file path starts with/*. shtml/, the file is forced to be processed by SSIServlet. If other file types such as. jsp and. jhtml are used, you can view unanalyzed JSP and JHTML code. Example: http://www.xxx.com/developer.shtmllogin.jsp

2. Use fileservlet forcibly to view the page that has not been analyzed:
WebLogic uses fileservlet to configure the consolehelp servlet. You can see the following content in the weblogic. properties file:

# For Console Help. Do not modify.
Weblogic. httpd. Register. consolehelp = weblogic. servlet. fileservlet
Weblogic. httpd. initargs. consolehelp = \ defaultfilename =/WebLogic/admin/help/nocontent.html
Weblogic.allow.exe cute. weblogic. servlet. consolehelp = everyone

So if the file path starts with/consolehelp/, WebLogic will use fileservlet to display unanalyzed or compiled files as pages, for example: http://www.xxx.com/ConsoleHelp/login.jsp

Solution:
Do not use the setting method in the example to set fileservlet. This may expose the source code of your JSP/JHTML file. Please refer to the online documentation:
Http://www.weblogic.com/docs51/admindocs/http.html#file

The registrations example is as follows:
Weblogic. httpd. Register. File = weblogic. servlet. fileservlet
Weblogic.httpd.initargs.file=defaultfilename=index.html
Weblogic. httpd. DefaultServlet = File

There are two ways to avoid this problem:

(1) register the File Servlet with a random user name, making it more difficult to guess. For example, use the following method to register a file: servlet is 12foo34:
Weblogic. httpd. register.12foo34 = weblogic. servlet. fileservlet
Weblogic.httpd.initargs.12foo34?defafilename=index.html
Weblogic. httpd. DefaultServlet = 12foo34

(2) register the File Servlet and use wild cards to declare that you will use all these file extensions for service. For example, register a File Servlet as A. html file service:
Weblogic. httpd. Register. *. html = weblogic. servlet. fileservlet
Weblogic. httpd. initargs. * .html?defafilename=index.html
Weblogic. httpd. DefaultServlet = *. html

use the above method to repeat the following types of files *. GIF ,*. JPG ,*. PDF ,*. TXT, etc.
Note: This information is documented in the BEA WebLogic Server and express documentation: http://www.weblogic.com/docs51/admindocs/lockdown.html
another: please pay attention to the new version and upgrade it.