A Preliminary Study on JSP Security

Summary: There are several ways to expose JSP Code But after a lot of tests, this has an absolute relationship with the Web server configuration. For IBM WebSphere Commerce Suite, there are other ways to see JSP Source code But I believe it is caused by the configuration of IBM HTTP server.

If you want to discover the bug of JSP Source Code exposure, you must first understand the working principle of JSP.

JSP is different from other PHP and ASP working mechanisms, although it is also a webProgramming Language. Calling the JSP file for the first time is actually a process of compiling servlet. Note that we need to do thisArticleDo you understand? What we want to do is to let JSP be sent to the client as a text or other file by the browser before compilation, or when the JSP is loaded, the compiled servlet is not executed, and the JSP content is directly read and sent to the client.

After understanding the truth and the purpose to be achieved, you can find that JSP is compiled to the servlet and saved in the specified directory, for example, callback. _ Lovehacker_index_xjsp.class is obviously a file we don't need, and we are unlikely to get it. What we need to do is not execute _ lovehacker_index_xjsp.class but directly read the content of index. jsp.

According to the analysis of the initial XXX. the source code exposed by JSP is also caused by the idea of the front edge. The original directory stores a _ xxx_xjsp.class, but accesses XXX. JSP is a legal request, and the corresponding servlet cannot be found. JSP is sent to the user as a text or other file.

This may be caused by improper configuration of the ibm http server, but I believe that if it succeeds, it will have a sense of accomplishment and a great job!

By the way, exposing the actual path of a file may cause harm:

1. First let intruders know about disk configurations
2. Clearly the intruders can even analyze the level of the Administrator
3. It provides convenience for intruders to modify your homepage (at least you don't need to find your web directory on that disk)
4. Some other CGI vulnerabilities may be exploited to find files in the web directory, such as XX. asp, XX. jsp, and XX. php.

What are the main aspects of JSP security issues?

This section focuses on the classification of JSP security issues and puts forward suggestions for solutions. Therefore, only one example is used for each type of security issues, for other specific details of various vulnerabilities such as the software version of which the operating system is not described one by one, interested readers can to JSP fans (http://jspbbs.yeah.net) or Foreign Security site (http://www.securityfocus.com) for viewing and reference.

Based on the existing JSP security issues, you may want to classify them into the following categories: source code exposure, remoteProgramFor the execution class and other categories, let's take a look at specific things.

I. Source Code exposure

The source code exposure category mainly refers to the type in which the program source code is returned to visitors in plaintext.
We know that dynamic programs, such as JSP, ASP, and PHP, are executed on the server. After execution, they only return standard HTML and other code to visitors. This is a theoretical thing. In practice, the internal mechanism of the server may cause the vulnerability of source code exposure, in a simple example, you only need to add a few simple characters after the program file name to obtain the program code, such as the common Microsoft ASP global. asa +. HTR, xxxx. vulnerabilities such as asp % 81.

1. JSP Source Code exposure caused by adding special suffixes

JSP also has issues similar to ASP vulnerabilities, such as JSP file suffix capitalization vulnerabilities such as IBM WebSphere Application Server 3.0.21, BEA Systems WebLogic 4.5.1, and tomcat3.1; add special characters such as % 82 and .. Of resin1.2 to the JSP file ,.. /vulnerabilities; % 2e and + vulnerabilities of ServletExec.

Example: For an old JSP capital example, Tomcat 8080 is originally http: // localhost:/inde in the browser. JSP, which can be interpreted and executed normally. change JSP to INDE. JSP or INDE. JSP and so on. You will find that the browser will prompt you to download this file. After downloading the source code, you can check the source code.

Cause: JSP is case sensitive. Tomcat will only execute the file with the lower-case JSP suffix as a normal JSP file. If it is capitalized, Tomcat will change the index. JSP is a downloadable file for customers to download. Earlier versions of Weblogic and webshpere all have this problem. Now these companies have released new versions or patches to solve this problem.

Solution: first, download the patch on the server software website. because the author has used ASP for a while and has been exposed to many IIS vulnerabilities, the effective solution is to remove unnecessary mappings such as HTR and htx. In JSP, we can also refer to the IIS solution to add mappings instead of removing mappings, the method is to add some mappings in the server settings, such. JSP ,. JSP ,. JSP % 2e and so on, map them to a self-written servlet, the only function of this servlet is to direct the request to a custom error page similar to 404 not found, different server settings are also different. Please refer to the relevant documentation. The second solution can be used when no patch is available.

2. inserting special strings causes JSP Source Code exposure

Another vulnerability is caused by inserting special strings, the BEA WebLogic Enterprise 5.1 file path starts with "/file/", IBM WebSphere 3.0.2 "/servlet/file/", and so on.

Example: in IBM WebSphere 3.0.2, if the URL of a request file is "login. jsp": Login.

Cause: IBM WebSphere 3.0.2 calls different Servlets to process different pages. If a requested file is not registered for management, WebSphere uses a default servlet call. 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.

Solution: download the latest patch from the server software website.

3. File JSP Source Code exposure caused by path Permissions

We know that most JSP applications have a WEB-INF directory under the current directory, which usually stores the class file compiled by JavaBeans, if you do not set normal permissions for this directory, all the classes will be exposed.

Example: If you use a web server in the form of apache1.3.12 and a third-party JSP software, the default setting of apache1.3.12 can read the directory.

Some people may say that the class is compiled, and it does not matter if it is downloaded. However, there are also a lot of software that decompile the class into Java code, someone used the Jad software to decompile the downloaded class file. It is almost the same as the original Java file, and the variable name has not changed, what's even more surprising is that it can be re-compiled into a class file for normal use.

The biggest security problem is that the Web Page Maker began to write the database username and password in Java code. Now, anyone who decompile can see the important information of the database. Through the remote connection function of the database, you can easily access your database, with all the information in its hands. Additionally, if you can obtain the username and password of SQL Server, You can execute any DOS commands such as viewing c: \ files, creating and deleting directories in the database, in this way, the entire Windows system is insecure.

Solution: In the past, IIS effectively solved the ASP Vulnerability by placing the ASP program in a separate directory. The user permissions on the directory settings can only be executed and cannot be read. In the JSP environment, you can also set the server environment to solve this problem. Simply put, you can set access permissions for important directories such as Web-INF and classes, read is not allowed and only execution is allowed. Take Apache solution as an example, you can add a directory WEB-INF In the httpd. conf file and set attributes such as deny from all.

Another kind of stupid solution is to upload a starting page such as index.htm in each important directory, so that the directory will be read and the file will be returned to the visitor instead of the other. Recommended method.

More importantly, the password is saved. In JSP, you can write a property file, place it in the WINNT system directory, and then use bean to read the database information. In this way, the source code shows that the database information exists in winnt. property file, but it is difficult to access it, so that even if the source code is known, at least the database is safe.

4. absolute path exposure caused by the absence of Files

I believe everyone is familiar with this problem, because Microsoft IIS also has many similar problems. For example, *. IDC in Microsoft iis5.0 exposes the absolute path vulnerability. The same problems are now transferred to the JSP environment. This vulnerability exposes the absolute hard disk address of the web program, and the combination of this vulnerability has a great harm.

Example: access a non-existent JSP file such as http: // localhost: 8080/fdasfas under a specific server software. JSP will return Java. servlet. servleteception: Java. io. filenotfoundeception: C: \ WEB \ app \ fadssad. JSP (???????????) In this way, the website may be under the c: \ WEB \ app Directory, which is very helpful for a hacker.

Cause: the exception is not filtered out when the servlet responsible for JSP execution handles exceptions.

Solution: first, download the latest patch. If the web server software didn't have the patch at the time, you can find the JSP execution servlet ing Servlet File of the server software (of course, the class suffix ), decompile the program with the Jad software, find the Exception Handling Method in the decompiled source code, and comment out all the processing parts in the method, and direct the request to a custom error page to solve the problem.

Ii. Remote Program Execution

This type of vulnerability is characterized by the ability to execute commands and programs on any server in the browser through the URL address, which causes security problems. For example, Allaire JRun 2.3 remote command execution vulnerability, iPlanet Web Server 4.x has a buffer overflow vulnerability, and so on.
Example: On JRun server 2.3 of Allaire, enter the following url: http: // JRun: 8000/servlet/JSP /.. /.. /path/sample.txt can access files other than the web directory. If it is an EXE file, it may also cause execution.

Cause: 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. This vulnerability is exploited on the target host to request a file generated by user input, which seriously threatens the security of the target host system.

Solution: install the latest patch.

Iii. Other categories

The scope of these categories is a little large, including database vulnerabilities such as SQL Server, Oracle, DB2, and other vulnerabilities, as well as operating system vulnerabilities such as WindowsNT/2000 and linu. Vulnerabilities in these things can be said to be fatal. For example, some Linux vulnerabilities can easily obtain administrator privileges to remotely control the server and obtain full control permissions of the system, in this way, it is much easier to obtain the JSP source code or destroy the server than to step on an ant.

Iv. Summary

Through the above content, we can see that there are still many security problems in JSP like ASP. Objectively speaking, server software developers cannot find all the bugs in the system during internal testing, even after the software is released, the discovered vulnerabilities will only be a small part of them, and new security problems will emerge in the future. Therefore, we must always be vigilant, pay attention to the security of your website.

A good suggestion is to read more security articles, which generally contain detailed information such as the software version number and vulnerability causes, the most important is also attached with the solution or 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 more patches, visit the home page of the software company you are using and obtain the latest patch from it. The good job is Microsoft's site. The Security announcements and patches are all very timely.

Finally, I want to end with a sentence: A good hacker is not necessarily a good JSP programmer, but a good JSP programmer must be a good quasi-hacker.

Which methods can be used to implement Java Servlet and JSP application security?

A Web application can have multiple types of resources, and many sensitive information is often transmitted over an open network without protection measures. In this environment, many web applications have certain security requirements. Most servlet containers have clear mechanisms and structures to meet such security requirements. Although the guarantee and execution details may be somewhat different, they all have the following features:

1. Authentication: the communication entity verifies each other's behavior by a clear identity mechanism.
2. Access Control for resources: for a group of users, some operations on the database are restricted, or a mechanism that emphasizes availability, integrity, or confidentiality for some programs.
3. Data Integrity: a mechanism that ensures that data is not modified by a third party during data transmission.
4. Confidentiality or data privacy: a mechanism that ensures that data is used only by authorized users and can be safely transmitted.

Java Servlet and JSP are implemented in the following ways:

1. Declarative Security

Declarative security refers to the security structure of an application, including role, access control, and verification required by external forms in an application. Describer is a major tool for implementing declarative security in Web applications.

The publisher maps the logical integrity required by the application to a security policy in a specific runtime environment. At runtime, Servlet iner uses these policies to force verification.

Ii. Programmatic Security

When declarative security cannot fully express an application security model, programmatic security can be used. Programmatic security includes the following methods for the httpservletrequest interface:
Getremoteuser
Isuserinrole
Getuserprincipal

The getremoteuser method returns the user name verified by the client. Isuserinrole asks container's security mechanism whether a specific user is in a given security role. The getuserprinciple method returns a java. Security. pricipal object. These APIs allow the servlet to complete some logical judgment based on the logic role of the remote user. It also allows the servlet to determine the main name of the current user. If getremoteuser returns NULL (which means no user is verified), isuserinrole always returns false, and getuserprinciple always returns NULL.

Iii. Roles

A roles is an abstract logical user group defined by application developer and consumer er. When an application is released, deployer maps these roles to security authentication in the runtime environment, such as group or rule.

A servlet container can execute some instructions or programming security for the rules, which are associated with the requirements entered to call these principal security attributes. For example:

1. When deployer maps a security role to a user group in the operating environment, the user group that calls principle is obtained from the security attribute. If the principle user group matches the user group in the operating environment, principle is a security role.
2. When deployeer maps a security role to a principle name in the security policy domain, the principle name called is extracted from the security attribute. If the two are the same, the principle called is safe.

Iv. Authentication

A Web Client can use the following mechanism to verify a user on the Web server.

HTTP digest Authentication
HTTPS client authentication
HTTP Basic Authentication
HTTP Based Authentication

V. HTTP Basic Authentication

HTTP basic authentication is a validation mechanism defined in the HTTP/1.1 specification. This mechanism is based on the user name and password. A Web server requires a Web client to verify a user. As part of the request, web server passes a string called realm, which is verified by the user. Note: The realm string of the basic authentication mechanism does not necessarily reflect any security policy domain. The Web Client obtains these usernames and passwords and passes them to the web server. Web server then verifies these users in a specific domain.

Because the password is transmitted using a 64-bit encoding and the target server is not verified, basic authentication is not a secure authentication protocol. However, some additional protection measures such as using a secure transmission mechanism (https) or using security measures at the network layer can solve some problems.

6. Http digest Authentication

Like HTTP digest authentication, HTTP digest authentication authenticates a user based on the user name and password. However, the transmission of passwords is encrypted, which is much safer than the 64-bit encoding used by basic authentication. This method is not secure as the personal key scheme of HTTPS client authentication. Because digest authentication is currently not widely used, servlet containers does not require support but encourages it.

VII. HTTPS client authentication

End-user authentication using HTTPS (HTTP over SSL) is a strict non-authentication mechanism. This mechanism requires users to process public key certification PKCS ). Currently, PKCS is useful in e-commerce applications. Servlet ininers that are not applicable to J2EE does not require HTTPS protocol.

8. Server tracking of authentication information

Just like the Security Identifier mapped to a role, the runtime environment is the description of the environment rather than the application.

1. Create a logon mechanism and policy in the Web application release environment.
2. Applications published in the same iner can use the same authentication information to represent the principal of these applications.
3. Users are required to re-verify the security policy domain.

Therefore, a servlet container requires that the authentication information be tracked at the container layer, rather than at the application layer. A verified user is allowed to deny an application that uses other resources, which are managed by the container restricted by the same security identifier.