js| Security | Server Overview: Server Vulnerabilities are the origin of security problems, hackers on the site is mostly from the search for the other side of the vulnerability began. Therefore, only by understanding their own vulnerabilities, site managers can take appropriate countermeasures to prevent foreign attacks. Here are some common vulnerabilities for servers, including Web servers and JSP servers.
What's wrong with Apache leaking any rewritten file vulnerabilities?
There is a mod_rewrite module in Apache1.2 and later versions that specifies the absolute path that special URLs map on the network server file system. If you pass an overriding rule that contains the correct expression parameters, an attacker can view arbitrary files on the target host.
The following examples illustrate the overriding rule directives (where the first line contains only the vulnerabilities):
How do I resolve to expose a JSP source code file by adding special characters to an HTTP request?
Unify Ewave Servletexec is a Java/java Servlet engine plug-in that is used primarily for WEB servers, such as Microsoft IIS, Apache, Netscape Enterprise servers, and so on.
When one of the following characters is added to an HTTP request, SERVLETEXEC returns the JSP source code file.
.
%2e
+
%2b
%5c
%20
%00
A successful exploit would result in the disclosure of the source code for the specified JSP file, for example: using any of the following URL requests to output the source of the specified JSP file:
If you do not use any static pages or images, you can configure a default servlet and map "/" to this default servlet. This default servlet is invoked when a URL that is not mapped to a servlet is received. In this case, the default servlet can simply return "files not found". If you use a static page or image, you can still make such a configuration, but you need to have this default servlet handle requests for legitimate static pages and images.
Another possibility is to map *.jsp+, *.jsp. and *.jsp\ to a servlet that simply returns "files not found." For cases such as *.jsp%00 and *.jsp%20, mappings should be entered in an encoded form. For example, you should enter "*.jsp" for *.jsp%20 mappings. Note that the%20 is converted to a space character.
What are the vulnerabilities of Tomcat?
Tomcat 3.1 has exposure site 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 sending a nonexistent JSP request exposes the full path of the Web page on the Web site.
Example:
http://narco.guerrilla.sucks.co:8080/anything.jsp
The results show:
error:404
Location:/anything.jsp
JSP file "/appsrv2/jakarta-tomcat/webapps/root/anything.jsp" not Found
Solution: Upgrade to new version
Tomcat exposes JSP file contents
Files in the Java Server Pages (JSP) type are registered with the '. JSP ' extension on Tomcat, and Tomcat is file-case sensitive, '. jsp ' and '. JSP ' is a different type of file name extension. If submitted with '. JSP ' link to Tomcat, and Tomcat cannot find '. The JSP ' will respond to the request with the default '. Text ' file type. Because uppercase and lowercase filenames are not sensitive in the NT system, the requested file is sent in the form of text.
If the "File not found" error message appears on the UNIX server.
How to implement code protection for Tomcat under Windows
Some versions of Tomcat have leaked source code vulnerabilities, if you call the JSP page in the browser to the file suffix to uppercase, the JSP file source code will be fully exported to the browser (perhaps there is nothing in the browser window, then you only need to view the HTML source file can be found). So, is the source code of the website will be exposed on the internet?
Do not worry, the solution is very simple, the combination of all kinds of suffixes written to tomcat_home\conf \web.xml can be, so that Tomcat will be different suffix name JSP treated separately, will not reveal 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 vulnerabilities?
Allair JRUN Illegal Read Web-inf vulnerability
There is a serious security vulnerability in the Allaire version of JRUN Server 2.3. It allows an attacker to view the Web-inf directory in the JRun 3.0 server.
If a user submits a URL request by appending a "/" to make the URL a malformed URL, then all subdirectories under Web-inf will be exposed. An attacker who exploits this vulnerability would be able to remotely obtain read access to all files in the Web-inf directory on the target host system.
For example, using the following URL will expose all files under Web-inf:
A multiple display code vulnerability exists on the Allaire 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 (for example, HTML, JSP, and so on). Based on rules.properties and servlets.properties file settings, any servlet may be invoked using the URL prefix "/servlet/".
It may use the Jrun ssifilter servlet to retrieve arbitrary files on the target system. The following 2 examples show URLs that can be used to retrieve arbitrary files:
Allaire JRUN 2.3 Remote execution of arbitrary command vulnerabilities
A security vulnerability exists on Allaire's JRUN server 2.3 that allows remote users to compile/execute arbitrary files on the WEB server as JSP code. 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.
JRun 2.3.x sample file exposes site security information
JRun 2.3.x has some servlet sample files under the Jrun_home/servlets directory, which is JRun 2.3.x for loading and executing servlets files. All extensions are ". Java "or" class "files must be deleted because these files expose the site's security information. For example:
Http://www.xxx.xxx/servlet/SessionServlet exposes the HTTP connection information maintained by the current server. The contents of the Jrun_home/jsm-default/services/jws/htdocs directory should also be deleted. This directory holds '. jsp ' files that demonstrate server functionality, some of which involve problems accessing the server's file system and exposing server settings. For example, the path check for the file "viewsource.jsp" is turned off by default and can be used to access the server file system.
Solution:
1) Install 2.3.3 Service Pack
2 Remove all documentation, demo codes, examples, and materials from the server, including the Jrun_home/servlets directory and Jrun_home/jsm-default/services/jws/htdocs when installing JRun 2.3.x The document in the directory.
Related sites: http://www.allaire.com/
What vulnerabilities are there in IBM WebSphere application server?
1. IBM WebSphere application Server 3.0.2 exposure Source Code Vulnerability
IBM WebSphere application Server allows an attacker to view all files above the Web Server root directory. IBM WebSphere uses Java servlets to process multiple page types of analysis (such as HTML, JSP, JHTML, and so on). In addition different servlets handle different pages, and if a requested file is not registered for administration, WebSphere uses a default servlet to invoke it. If the file path starts with "/servlet/file/" the default servlet will be invoked this requested file will be displayed without parsing or compiling.
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 then Access http://site.running.websphere/servlet/ File/login.jsp will see the source code for this file.
Related sites: http://www-4.ibm.com/software/webservers/appserv/
IBM WebSphere Application Server exposes JSP file contents
Files in the Java Server Pages (JSP) type are registered with the '. JSP ' extension on the WebSphere application Serve, and WebSphere is file-case sensitive, '. jsp ' and '. JSP ' is a different type of file name extension. If submitted with '. JSP ' link to WebSphere, and WebSphere cannot find '. The JSP ' will respond to the request with the default '. Text ' file type. Because uppercase and lowercase filenames are not sensitive in the NT system, the requested file is sent in the form of text.
If the "File not found" error message 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 are the BEA WebLogic exposed source code vulnerabilities?
Affected version:
All systems on the
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 could allow an attacker to read the source code of all files in the Web directory.
WebLogic relies on four main Java servlets to services of 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
Looking at the Weblogic.properties file, here are the registration values for each servlets:
More weblogic.properties files, if a request file is not registered, then a default servlet is invoked. The following is a demonstration of how the default servlet is registered.
# 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/", it will cause the WebLogic to invoke the default servlet, which will cause the page to be displayed directly without parsing and compiling.
Argument:
As long as you want to see the file before the original URL path to add "/file/" will make the file without analysis and compilation, direct exposure to the source code. such as: http://site.running.weblogic/login.jsp, so as long as access to http://site.running.weblogic/file/login.jsp will be in the WEB browser to see the contents of the file.
Here's how to use it:
1. View the pages that are not parsed by forcing the use of Ssiservlet:
The server site processes the page through the Ssiservlet in WebLogic, which registers the following information in the Weblogic.properties file: weblogic.httpd.register.*.shtml= Weblogic.servlet.ServerSideIncludeServlet
Use Ssiservlet to automatically process wildcard characters (*) by using a URL. Therefore, if the file path begins with/*.shtml/, the file is forced to be processed by Ssiservlet. If you use other file types such as. jsp and. Jhtml, you can view the not-parsed JSP and jhtml code. Example: http://www.xxx.com/*.shtml/login.jsp
2. View the pages that are not parsed by forcing the use of Fileservlet:
WebLogic uses Fileservlet to configure the Consolehelp servlet, which is known in the following sections of weblogic.properties files:
Therefore, if the file path starts with/consolehelp/, it will cause the WebLogic to use Fileservlet to make the parsed or compiled file appear as a page, 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 check the online documentation:
(2) The register file servlet uses wild cards to declare that you will use all these files to extend the Masterpiece service. Example registers a file servlet for the. html File service:
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
