Preliminary study on JSP security _jsp programming

Summary: There are several ways to expose JSP code, but after a lot of testing, which is absolutely related to the configuration of the Web server, take the IBM Websphere Commerce Suite, there are other ways to see the JSP source code, but believe that the IBM HTTP The configuration of the server.

If you want to find JSP exposed source code bug, first need to understand how JSP works.

JSP and other PHP, ASP working mechanism is not the same, although it is also a web programming language. The first call to the JSP file is actually a process that compiles to a servlet. Look, we're going to do this on the top, okay? The thing we want to do is to have the JSP sent to the client by the browser as a text or other file before compiling, or to read the contents of the JSP directly to the client while the JSP is loaded without performing the compiled servlet.

Understand the truth and to achieve the purpose of a good start, careful observation of the call and return process can be found: JSP is compiled for the servlet to save in the specified directory, such as: http://www.x.com/lovehacker/index.jsp is likely to be stored in the X:\ Ibm\waserver\temp\default_host\default_app\pagecompile\_lovehacker_index_xjsp.class, this is the index.jsp that has been compiled. _lovehacker_index_xjsp.class is obviously a document we don't need, and we're not very likely to get it, but instead of doing _lovehacker_index_xjsp.class, we're just going to read index.jsp content.

According to the analysis of the initial XXX. The JSP exposes the source code also because of this kind of idea in the front, the original directory has stored a _xxx_ Xjsp.class, but access to xxx.jsp was a legitimate request, and the corresponding servlet was not found so the xxx.jsp was sent to the user as a text or other file.

Perhaps this is due to the improper configuration of IBM HTTP server, but I believe that if successful, there will be a sense of achievement, very cool Oh!

By the way, exposing the actual path to the file can be harmful:

1. Let the intruder know about the disk configuration first
2. Ming intruders can even analyze the level of administrator
3. It's convenient for intruders to modify your home page (at least you don't need to find your web directory on that disk)
4. may be exploited by some other CGI vulnerabilities to find files in a web directory such as Xx.asp, XX. JSP, XX. PHP and other

What are the main aspects of JSP security issues?

This section focuses on the JSP security issues to classify and propose solutions, so for each type of security problem, only one example is used, and the specific details of other vulnerabilities, such as which software version and which operating system are involved, are not elaborated, and interested readers can go to JSP enthusiasts (HTTP ://jspbbs.yeah.net) or foreign security site (http://www.securityfocus.com) for viewing and reference.

According to the existing JSP security issues have been found, you may want to divide them into the following categories, source code exposure classes, remote program execution classes and other categories, let's look at the specific things.

First, source code exposure class

The source code exposure category refers primarily to the way the program source code is returned to the visitor in clear text.
We know whether JSP or ASP, PHP and other dynamic programs are executed on the server side, the implementation will only return to the visitor standard HTML code. This is a theoretical thing, actually running because of the internal mechanism of the server can cause the source code exposure vulnerabilities, simple examples as long as the program file name after adding a few simple characters can get program code, such as the Common Microsoft ASP global.asa+.htr, xxxx.asp% 81 and so on loopholes.

1. Adding a special suffix causes JSP source code to be exposed

Problems similar to those in the ASP are also present in the JSP, such as the IBM Websphere application Server 3.0.21, the BEA Systems Weblogic 4.5.1, Tomcat3.1, and other JSP file suffix capitalization vulnerabilities; JSP Furu Resin1.2 with special characters after the file%82 、.. /vulnerabilities, servletexec of%2e, + vulnerabilities, and so on.

Example: An older example of JSP capitalization, Tomcat3.1 in the browser is originally http://localhost:8080/ INDE.JSP, you can normally explain the implementation, but if the inde.jsp changed to inde.jsp or inde.jsp wait and see, you will find that the browser will prompt you to download the file, download the source code can be seen.

Reason: JSP is case sensitive, Tomcat will only lowercase jsp suffix file as a normal JSP file to execute, if uppercase will cause Tomcat will index.jsp as a downloadable file for customers to download. This is the problem with older versions of WebLogic, Webshpere, and so on, and now these companies have either released a new version or released patches to solve the problem.

Solution: First, on the Server Software Web site download patches; Because the author used ASP for a period of time, exposure to 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 also refer to the IIS solution, Instead of removing it, you add a mapping by adding some mappings to the server settings such as. Jsp. JSP,. jsp%2e, etc., map them to a written servlet, the only function of this servlet is to direct the request to a custom-like 404 Not Found error page, different server settings are different, please refer to the appropriate documentation. The second solution can be used when there are no patches.

2. Inserting a special string causes the JSP source code to be exposed

Another is the vulnerability that is caused by inserting a special string, the WebLogic Enterprise 5.1 file path begins with a "/file/" vulnerability, IBM WebSphere 3.0.2 's "/servlet/file/" file opening vulnerability, and so on.

Example: In IBM WebSphere 3.0.2, 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.

Reason: Because IBM WebSphere 3.0.2 is calling different servlets to handle different pages, WebSphere uses a default servlet call if a requested file is not registered for administration. If the file path starts with "/servlet/file/" the default servlet will be invoked this requested file will be displayed without parsing or compiling.

Workaround: Download the latest patches on the Server Software Web site.

3. File JSP source code exposure caused by path permissions

We know that most JSP applications in the current directory will have a web-inf directory, this directory usually contains JavaBeans compiled class files, if not to the directory to set normal permissions, all class will be exposed.

Example: If you are using a Web server in the form of Apache1.3.12 plus third-party JSP software, because the Apache1.3.12 default setting is to read the directory, if the program is in Http://site.running.websphere/ login.jsp, just modify the http://site.running.websphere/WEB-INF/all of this directory and this directory under the subdirectory of the class file can be seen a full, but also can be downloaded to the computer.

Some people may say that class is compiled, even if it is not related to the download, but now class decompile to Java code software is also a lot of people once used jad software to download the class file decompile, incredibly and the original Java file almost exactly the same, The variable names have not changed, and what is more surprising is that you can recompile the class file for normal use.

A bigger security issue is that web page makers are starting to write the username and password of the database in Java code, and now anyone can see the important information of the database in a decompile. Through the remote connection function of the database, it can easily enter into your database, all the information is in his hand. Incidentally, if users can get SQL Server username password, access to the database can execute arbitrary DOS commands such as view C:\ files, create and delete directories, etc., so that the entire Windows system is not secure.

WORKAROUND: An efficient way to resolve ASP vulnerabilities before IIS is to place an ASP program in a separate directory, where user rights can only be performed without reading. In the JSP environment can also be set up by setting up the server environment to solve this problem, simply, that is, some of the more important directories such as web-inf, classes, such as access to the permissions, not allowed to read and take only allowed to execute. In the case of Apache workaround, you can add a directory Web-inf to the httpd.conf file and set the Deny from all attribute.

Another stupid solution is to add a default starting page, such as index.htm, to each important directory, so that reading the directory will return to the visitor's file instead of the other. A recommended method of use.

More important is the problem of saving passwords. In the JSP can write a property file, placed in the Winnt system directory, and then use the bean to read the database information, This way through the source code to know that the database information exists in the Winnt in the. property file, but also difficult to access it, so even if the source code is known that the minimum database is safe.

4. Absolute path exposure problems caused by file absence

This question is believed that everybody is familiar, because Microsoft IIS also has the quite many similar problems. As in Microsoft IIS5.0, *.IDC exposes absolute path vulnerabilities. The same problems have now been transferred to the JSP environment, which exposes the Web program's absolute hard disk address, and other vulnerabilities combined with a relatively large harm

Example: Under a specific server software, access to a non-existent JSP file such as http://localhost:8080/fdasfas.jsp, will return Java.servlet.ServletEception: java.io.filenotfoundeception:c:\web\app\fadssad.jsp (???????????) Such a mistake, so that you can know the site in the C:\web\app directory, perhaps the General people do not care, but for a hacker is very helpful.

Reason: This is not filtered out when handling exceptions in the relevant servlet that is responsible for JSP execution.

Solution: First, download the latest patches; If the Web server software did not have this patch, you can find the Server Software JSP implementation mapping servlet file (of course, the class suffix), it with Jad software decompile, Find a way to handle exception in the back-compiled source code, and then annotate all the processing parts in the method and direct the request to a custom error page, which solves the problem.

Second, the remote program execution class

Such vulnerabilities are characterized by the use of URL addresses in the browser to execute arbitrary server commands and programs, resulting in security issues. such as Allaire JRUN 2.3 Remote execution of arbitrary command vulnerabilities, IPlanet Web Server 4.x a buffer overflow vulnerability, and so on.
Example: Allaire's JRUN server 2.3, enter the following URL address http://jrun:8000/servlet/jsp/../../path/sample.txt, access to files outside the Web directory, if it is EXE file, may also cause execution.

Reason: 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.

Workaround: Install the latest patches.

Iii. Other Categories

The scope of these categories is a bit large and can include vulnerabilities such as SQL Server, Oracle, DB2, and so on, as well as operating systems such as windowsnt/2000, Linu, and so on. These vulnerabilities can be said to be fatal, such as the use of some Linux vulnerabilities can easily get administrator privileges to remotely control the server, get the full control of the system, so to get the JSP source code or destroy the server than to trample on an ant is much easier.

Iv. Summary of the full text

Through the above content can be seen JSP and the same as the ASP still exist a lot of security problems, objectively speaking, the server software developers in the internal testing is not possible to find all the bugs in the system, even if the software released, the discovered vulnerability will only be a small part of it, There will be new security problems in the future, so we must always be vigilant and pay attention to the safety of our website.

A good suggestion is to read more security articles, these security articles will generally have detailed information such as the version number of software, vulnerabilities, and so on, the most important thing is also shipped with a solution or a patch download link, the recommended security site is the domestic security site www.cnns.net or foreign http:// www.securityfocus.com site; Another good suggestion is to install multiple patches, visit the company homepage of the software you are using, get the latest patches from there, and do a better job of Microsoft's site, security bulletins and patches are especially timely.

Finally want to use a sentence as the end of the full text: A good hacker is not necessarily a good JSP programmer, a good JSP programmer must be a good quasi-hacker.

What are the ways to implement Java Servlet and JSP application security?

A Web application can have multiple resources and often has many sensitive information that is transmitted over an open network without protection. In this environment, many Web applications actually have some degree of security requirements. Most servlet containers have a clear mechanism and structure to meet this security requirement. Although the details of the warranty and execution may be different, they all have the following characteristics:

1. Authentication: Communication entities authenticate each other's behavior as a mechanism to be carried out in a clear identity.
2. Access Control for resources: some operations on a database are limited to a group of users, or a mechanism that emphasizes usability, integrity, or confidentiality for some programs.
3. Data Integrity: A mechanism for ensuring that a third party is not modified in the course of transmission.
4. Confidentiality or data privacy: a mechanism that guarantees that data is used only by those users who are authorized to use it and can be safely delivered.

Security in the Java servlet,jsp is implemented in several ways:

First, declarative security

Declarative security refers to the expression of an application's safety structure, including roles, access control, and validation required in an application's external form. Publishing descriptors in Web application is a major tool for implementing declarative security.

The Publisher maps the logical integrity required by application to a security policy in a specific running environment. At run time, the servlet container uses these policies to force validation.

Second, programmatic security

When declarative security cannot fully express a application safety model, it can be used programmatic. Programmatic security includes the following methods of the HttpServletRequest interface:
Getremoteuser
IsUserInRole
Getuserprincipal

The Getremoteuser method returns the user name authenticated by the client. IsUserInRole the security mechanism of the container to ask whether a particular user is in a given security role. The Getuserprinciple method returns a Java.security.Pricipal object. These APIs allow the servlet to perform some logical judgments based on the logical role of the remote user. It also allows the servlet to determine the main name of the current user. If Getremoteuser returns a null value (which means that no user is authenticated), then IsUserInRole always returns false,getuserprinciple always returns NULL.

Third, Roles

A roles is an abstract logical user group defined by application developer and assembler. When a application is released, Deployer maps these roles to security authentication in the operating environment, such as groups or rules.

A servlet container can perform some descriptive or programmatic security for the rule, which is associated with the requirements entered in the security attributes that invoke these principal. For example:

1. When Deployer maps a security role to a user group in the operating environment, the user group to which the principle belongs is obtained from the security attribute. If the principle user group matches the user group in the operating environment, then principle is a security role.
2. When Deployeer maps a security role to a principle name in the security policy domain, the call principle indeed principle name is extracted from the security attribute. If the two are the same, the invoked principle is safe.

Four, authentication

A Web client can use one of the following mechanisms to authenticate a user to a Web server.

HTTP Digest Authentication
HTTPS Client Authentication
HTTP Basic Authentication
HTTP Based Authentication

Five, HTTP Basic authentication

HTTP Basic Authentication is a validation mechanism defined in the http/1.1 specification. This mechanism is based on user name and password. A Web server requires a Web client to authenticate a user. As part of the request, the Web server passes a string called realm, which is validated by the user. Note: The realm string for the Basic authentication mechanism does not necessarily reflect any one of the security policy domains. The Web client gets these username and password and passes it to the Web server. The WEB server then validates these users in a specific domain.

Basic authentication is not a secure authentication protocol because the password is passed using a 64-bit encoding and the destination server is not validated. However, some additional protections like using a secure transport mechanism (HTTPS) or using security measures at the network level can solve some of the problems.

Vi. HTTP Digest Authentication

As with the HTTP Digest authentication, HTTP Digest authentication authenticates a user based on the user name and password. However, the transmission of the cipher is done in an encrypted form, which is much more secure than the 64-bit encoded form used by Basic authentication. This method does not secure a personal key scheme like the HTTPS Client authentication. Because Digest authentication is not currently widely used, servlet containers does not require support for it but encourages it to support it.

Vii. HTTPS Client Authentication

Terminal user authentication using HTTPS (HTTP over SSL) is a strict, unauthenticated mechanism. This mechanism requires the user to deal with public key proof (certification PKC). Currently, a PKCS is useful in e-commerce applications. servlet containers that do not adapt to Java EE do not require support for HTTPS protocols.

VIII. Server Tracking of authentication information

Like a security identity mapped in a role, the runtime environment is a description of the environment rather than an application.

1. Create a login mechanism and policy in the Web application publishing environment.
2. Application that are published in the same container can use the same validation information to represent the principal of these application.
3. The user is required to authenticate only when passing through the security policy domain.

Therefore, a servlet container requires that the validation information be tracked at the container level, rather than at the application level. Allows a proven user to reject a application that uses other resources, managed by container that are subject to the same security identity.