JSP vulnerability overview

Time:2022-5-6

Summary: server vulnerabilities are the origin of security problems. Hackers’ attacks on websites mostly start from finding each other’s vulnerabilities. Therefore, only by understanding their own vulnerabilities, website managers can take corresponding countermeasures to prevent foreign attacks. The following describes the common vulnerabilities of some servers (including web server and JSP server).

What’s the matter with Apache’s disclosure of rewritten arbitrary file vulnerability?

In Apache 1 There is a mod in version 2 and later_ Rewrite module, which is used to specify the absolute path mapped by special URLs on the network server file system. If a rewrite rule containing correctly expressed parameters is passed, an attacker can view arbitrary files on the target host.

The following is an example of rewriting rule instructions (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 system: Apache 1.3.13

How to solve the problem of exposing JSP source code files by adding special characters in HTTP requests?
Unify ewave servletexec is a Java / java servlet engine plug-in, which is mainly used for web servers, such as Microsoft IIS, Apache, Netscape enterprise server, etc.
When one of the following characters is added to an HTTP request, servletexec will return the JSP source code file.
.

  %2E
  +
  %2B
  \
  %5C
  %20
  %00  

Successful exploitation of this vulnerability will lead to the disclosure of the source code of the specified JSP file. For example, using any of the following URL requests will 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 you do not use any static pages or images, you can configure a default servlet and map “/” to this default servlet. In this way, when a URL that is not mapped to a servlet is received, the default servlet will be called. In this case, the default servlet can simply return “file not found”. If you use static pages or images, you can still make such a configuration, but you need to let the default servlet handle requests for legitimate static pages and images.
Another possibility is to add * jsp+、*. jsp. And * JSP \ and so on are mapped to a servlet, which just returns “file not found”. For * JSP% 00 and * In the case of jsp%20, the mapping should be entered in an uncoded form. For example, for * The mapping of JSP% 20 should enter “*. JSP”. Note that% 20 is converted to a space character.

What are the vulnerabilities of Tomcat?

Tomcat 3.1 exposes website paths

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

Examples:
  http://narco.guerrilla.sucks.co:8080/anything.jsp

The results show that:
Error: 404
Location: /anything.jsp
JSP file “/appsrv2/jakarta-tomcat/webapps/ROOT/anything.jsp” not found

Solution: upgrade to the new version

Tomcat exposes JSP file content

Files of Java Server Pages (JSP) type start with ‘ JSP ‘extension is registered on tomcat, which is case sensitive for file names JSP ‘and’ JSP ‘is a different type of file extension. If there is a ‘ JSP ‘link to tomcat, but Tomcat can’t find’ JSP ‘will be the default’ Text ‘file type to respond to the request. Because case file names are not sensitive in NT system, the requested file will be sent out in the form of text.

If the error message “file not found” appears on the UNIX server.

How to implement code protection for Tomcat under Windows

Some versions of Tomcat have the vulnerability of leaking the source code. If you change the suffix of the JSP file to uppercase when calling the JSP page in the browser, the source code of the JSP file will be completely output to the browser (maybe there is nothing in the browser window, at this time you can find it by looking at the HTML source file). In this way, will the source code of the website be exposed on the Internet?
Don’t worry. The solution is very simple. Write all combinations of suffixes to Tomcat_ Home\conf \web. XML, so Tomcat will treat JSPS with different suffixes separately and will not disclose the code.

    jsp
    *.jsp

    jsP
    *.jsP

   ?lt;servlet-name>jSp
    *.jSp

    jSP
    *.jSP

    Jsp
    *.Jsp

    JsP
    *.JsP

    JSp
    *.JSp

    JSP
    *.JSP

What are the vulnerabilities of allair jrun?

Allair jrun illegal reading WEB-INF vulnerability
There is a serious security vulnerability in Allaire’s jrun server version 2.3. It allows an attacker to view the WEB-INF directory in the jrun 3.0 server.
If the user adds a “/” to make the URL a malformed URL when submitting a URL request, all subdirectories under the WEB-INF will be exposed. By skillfully exploiting this vulnerability, the attacker will be able to remotely obtain the read permission of all files in the WEB-INF directory of the target host system.
For example, using the following URL will expose all files under 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 view arbitrary file vulnerability

There is a multiple display code vulnerability on Allaire’s jrun server 2.3. This vulnerability allows an attacker to view the source code of any file in the root directory on the web server.
Jrun 2.3 uses Java servlets to parse various types of pages (such as HTML, JSP, etc.). Based on rules Properties and servlets The file setting of properties may call any servlet with the URL prefix “/ servlet /”.
It may use jrun’s ssifilter servlet to retrieve arbitrary files on the target system. The following two examples show URLs that can be used to retrieve any file:

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 jrun is running on the host “jrun”, 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 arbitrary Command Execution Vulnerability

There is a security vulnerability in Allaire’s jrun server 2.3, which 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. At this time, using “.. /” in the target file path requested by the user may access files outside the root directory on the web server. Using this vulnerability to request user input to generate a file 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 example files expose site security information

  JRun 2.3. X in jrun_ There are some servlet sample files in the home / servlets directory. This directory is jrun 2.3 X is used to load and execute servlets files. All files with the extension “. Java” or “class” must be deleted because they will expose the security information of the site. For example:
http://www.xxx.xxx/servlet/SessionServlet The HTTP connection information maintained by the current server will be exposed. JRUN_ The contents in the home / JSM default / services / JWs / HtDocs directory should also be deleted. This directory holds the ‘demo server functions’ JSP ‘files, some of which involve accessing the server file system and exposing server settings. For example, the path check of the file “viewsource. JSP” is turned off by default, which can be used to access the server file system.

Solution:

1) install 2.3.3 service pack
2) delete all instruction documents, demonstration codes, examples and teaching materials from the server, including the installation of jrun 2.3 X is stored in jrun_ Home / servlets directory and jrun_ Documents in the home / JSM default / services / JWs / HtDocs directory.
Related sites: http://www.allaire.com/

What are the vulnerabilities of IBM WebSphere Application Server?

1. IBM WebSphere Application Server 3.0.2 has a source code exposure vulnerability
IBM WebSphere Application Server allows attackers to view all files above the web server root directory. IBM WebSphere uses Java servlets to handle the analysis of multiple page types (such as HTML, JSP, jhtml, and so on). In addition, different servlets process different pages. If a requested file is not registered and managed, WebSphere will use a default servlet for calling. If the file path starts with “/ servlet / file /”, the default servlet will be called, and the requested file will be displayed without analysis or compilation.

Affected systems: all versions of IBM WebSphere 3.0.2

Examples:

If the URL of a request file is “login. JSP”: http://site.running.websphere/login.jsp So visit http://site.running.websphere/servlet/file/login.jsp You will see the source code of this file.
Solution: Download and install the patch
http://www-4.ibm.com/software/webservers/appserv/efix.html
Related sites: http://www-4.ibm.com/software/webservers/appserv/
IBM WebSphere Application Server exposes JSP file contents
Files of Java Server Pages (JSP) type start with ‘ JSP ‘extension is registered on websphere application server. WebSphere is case sensitive for file names JSP ‘and’ JSP ‘is a different type of file extension. If there is a ‘ JSP ‘is linked to WebSphere, but WebSphere cannot find’ JSP ‘will be the default’ Text ‘file type to respond to the request. Because case file names are not sensitive in NT system, the requested file will be sent out in the form of text.

If the error message “file not found” appears on the UNIX server.

Solution: click here to download the patch
Related sites: http://www-4.ibm.com/software/webservers/appserv/efix.html
What source code vulnerabilities does bea Weblogic expose?

Affected version:

On 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 an attacker to read the source code of all files in the web directory.

Weblogic relies 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 includes page
3) pagecompileservlet – for jhtml page
4) JspServlet – for Java Server Page

Look at Weblogic Properties file, here is the registered value of each servlet:

  1)weblogic.httpd.register.file=weblogic.servlet.FileServlet
  2)weblogic.httpd.register.*.shtml=weblogic.servlet.ServerSideIncludeServlet
  3)weblogic.httpd.register.*.jhtml=weblogic.servlet.jhtmlc.PageCompileServlet
  4)weblogic.httpd.register.*.jsp=weblogic.servlet.JSPServlet
More Weblogic Properties file. If a request file is not registered and managed, 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 web page without analysis and compilation.

Argument:

As long as “/ file /” is added before the original URL path of the file you want to see, the file will be exposed without analysis and compilation. For example: http://site.running.weblogic/login.jsp , then just visit http://site.running.weblogic/file/login.jsp You will see the contents of the file in the web browser.

Here’s how to use it:

  1. View unparsed pages by forcing the use of ssiservlet:
The server site processes pages through ssiservlet in Weblogic, which is in Weblogic Register the following information in the properties file: Weblogic httpd. register.*. shtml= weblogic. servlet. ServerSideIncludeServlet

Use ssiservlet to automatically process wildcards (*) through URLs. So if the file path starts with / * Shtml /, which forces the file to be processed by ssiservlet. If other file types are used, such as JSP and Jhtml, you can view the unparsed JSP and jhtml code. give an example: http://www.xxx.com/ *.shtml/login. jsp

  2. View unparsed pages by forcing fileservlet:
Weblogic uses fileservlet to configure the consolehelp servlet in Weblogic The following contents of the properties file can be known:

# 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.execute.weblogic.servlet.ConsoleHelp=everyone  

Therefore, if the file path starts with / consolehelp /, Weblogic will use fileservlet to display the 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 up fileservlet. This may expose the source code of your JSP / jhtml file. Please check the online documentation:
  https://imgs.developpaper.com/imgs/, *.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.