Discussion on JSP security


Overview: there are several ways to expose JSP code, but after a large number of tests, it has an absolute relationship with the configuration of web server. Take IBM WebSphere commerce suite for example, 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 find the bug that JSP exposes the source code, you first need to understand the working principle of JSP.

JSP is different from other PHP and ASP working mechanisms, although it is also a web programming language. The first call to a JSP file is actually a process of compiling into a servlet. Notice that we’re going to write here, okay? What we need to do is to let the JSP be sent to the client as a text or other file by the browser before compilation, or directly read the content of the JSP and send it to the client without executing the compiled servlet when the JSP is loaded.

If you understand the reason and the purpose you want to achieve, you can start. After carefully observing the call and return process, you can find that JSP is compiled as a servlet and saved in the specified directory, such as: http://www.x.com/lovehacker/index.jsp It is likely to be stored in X: \ IBM \ waserver \ temp \ default_ host\default_ app\pagecompile\_ lovehacker_ index_ xjsp. Class, which is the compiled index jsp。_ lovehacker_ index_ xjsp. Class is obviously a file we don’t need, and it’s unlikely that we can get it. What we have to do is not to implement it_ lovehacker_ index_ xjsp. Class, but read index directly JSP.

According to the analysis, the original XXX The exposure of JSP source code is also caused by the previous idea. One is stored in the original directory_ xxx_ xjsp. Class, but visit XXX JSP was originally a legal request, but the corresponding servlet could not be found, so XXX The JSP is sent to the user as a text or other file.

Maybe this is caused by the improper configuration of IBM HTTP server, but I believe that if it can succeed, there will be a sense of achievement. It’s great!

By the way, the possible harm of exposing the real path of file storage:

1. Let the intruder know the disk configuration first
2. Ming invaders can even analyze the level of administrators
3. It provides convenience for intruders to modify your home page (at least you don’t have 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、XX. PHP, etc

What are the main aspects of JSP security?

This section focuses on the classification and description of JSP security problems and puts forward suggestions to solve them. Therefore, only one example is used for each type of security problems. The specific details of other vulnerabilities, such as what software version and what operating system are involved, are not explained one by one. Interested readers can go to JSP enthusiasts( http://jspbbs.yeah.net )Or foreign security sites( http://www.securityfocus.com )For viewing and reference.

According to the JSP security problems that have been found so far, we might as well divide them into the following categories: source code exposure class, remote program execution class and other categories. Let’s take a look at the specific things.

I. source code exposure class

The source code exposure category mainly refers to that the program source code will be returned to the visitor in clear text.
We know that no matter JSP, ASP, PHP and other dynamic programs are executed on the server side. After execution, they will only return standard HTML and other codes to visitors. This is something in theory. In practice, due to the internal mechanism of the server, it may cause loopholes exposed in the source code. For a simple example, as long as you add a few simple characters after the program file name, you may get the program code, such as the common Microsoft ASP global asa+. htr、XXXX. Asp%81 and other vulnerabilities.

1. Adding a special suffix causes JSP source code exposure

There are also problems similar to those of ASP in JSP, such as IBM WebSphere Application Server 3.0.21, BEA systems Weblogic 4.5.1 and tomcat3 1. JSP file suffix capitalization vulnerability; JSP file followed by special characters, such as resin1 % 82/ loophole; Servletexec’s% 2E, + vulnerabilities, etc.

Example: take an old JSP uppercase example, tomcat3 1 in the browser http://localhost:8080/inde.jsp , it can be interpreted and executed normally, but if inde 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, you can have a clean look at the source code.

Reason: JSP is case sensitive. Tomcat will only execute the file with lowercase JSP suffix as a normal JSP file. If it is capitalized, Tomcat will index JSP is regarded as a downloadable file for customers to download. Old versions of Weblogic and WebShpere all have this problem. Now these companies have either released new versions or released patches to solve this problem.

Solution: first, download the patch on the website of the server software; Because the author used ASP for a period of time before and came into contact with many IIS vulnerabilities, its effective solution is to remove unnecessary mappings, such as HTR, HTx, etc. in JSP, we can also refer to the solution of IIS. The difference is not to remove but to add mappings. The method is to add some mappings in server settings, such as JSP 、. Jsp、. JSP% 2E, etc. map them to a servlet written by yourself. 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 corresponding documents. The second solution can be adopted when there is no patch.

2. JSP source code exposure caused by inserting special strings

There is also a vulnerability caused by inserting a special string, such as the vulnerability with “/ file /” at the beginning of BEA Weblogic enterprise 5.1 file path, the vulnerability with “/ servlet / file /” at the beginning of IBM WebSphere 3.0.2 file, and so on.

Example: for example, in IBM WebSphere 3.0.2, if the URL of a request file is “login. JSP”: http://site.running.websphere/login.jsp , then visit http://site.running.websphere/servlet/file/login.jsp You will see the source code of this file.

Reason: IBM WebSphere 3.0.2 calls different servlets to process different pages. If a requested file is not registered and managed, WebSphere will use a default servlet call. 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.

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

3. File JSP source code exposure caused by path permission

We know that most JSP applications will have a WEB-INF directory in the current directory. This directory usually stores the class files compiled by JavaBeans. If normal permissions are not set to this directory, all classes will be exposed.

Example: if you use Apache 1 3.12 add a web server in the form of third-party JSP software, because Apache 1.1 3.12 the default setting is that the directory can be read if the program is in http://site.running.websphere/login.jsp , just modify it http://site.running.websphere/WEB-INF/ All the class files in this directory and its subdirectories can be seen and downloaded to this computer.

Some people may say that class has been compiled. Even if it is downloaded, it doesn’t matter. But now there are many software that decompiles class into Java code. Someone used JAD software to decompile the downloaded class file, but it is almost the same as the original java file. The variable name hasn’t changed. What’s more, it can be recompiled into a class file for normal use.

The bigger security problem is that web page makers began to write the user name and password of the database in Java code. Now, once decompiled, everyone can see the important information of the database. Through the remote connection function of the database, you can easily enter your database, and all the information is in his hands. Incidentally, if the user can obtain the user name and password of SQL server and enter the database, he can execute any DOS commands, such as viewing C: \ files, establishing and deleting directories, etc., the whole windows system is not safe.

Solution: an effective way for IIS to solve ASP vulnerabilities in the past is to place ASP programs in a separate directory. The user permissions on the directory settings can only be executed and cannot be read. In the JSP environment, this problem can also be solved by setting the server environment. In short, it is to set the access permissions on some important directories such as WEB-INF and classes, which are not allowed to read, but only allowed to execute. Taking Apache as an example, it can be solved in httpd Add a directory WEB-INF to the conf file and set deny from all and other attributes.

Another stupid solution is to add a default start page under each important directory, such as index Htm, etc., so that reading the directory will return this file to the visitor instead of others. A suggested method.

More importantly, the preservation of passwords. You can write a property file in JSP, place it in the WinNT system directory, and then use bean to read the database information. In this way, you can know the existence of the database information in WinNT through the source code Property file, but it is also difficult to access it, so that even if the source code is known, at least the database is secure.

4. There is no absolute path exposure problem caused by the file

I believe you are familiar with this problem, because there are many similar problems in Microsoft IIS. Such as Microsoft iis5 *. In 0 IDC exposes 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, which is more harmful when combined with other vulnerabilities

Example: access a non-existent JSP file under a specific server software, such as http://localhost:8080/fdasfas.jsp , it will return Java servlet. ServletEception: Java. io. FileNotFoundEception: c:\web\app\fadssad. jsp (???????????) Such a mistake, so you can know that the website is in the C: \ web \ app directory. Maybe ordinary people don’t care much, but it’s very helpful for a hacker.

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

Solution: first, download the latest patch; If the web server software at that time did not have this patch, you can find the JSP execution mapping servlet file of the server software (class suffix of course), decompile it with JAD software, find the method to deal with exceptions in the decompiled source code, comment out all the processing parts in the method, and direct the request to a custom error page. In this way, the problem is solved.

II. Remote program execution

The characteristic of this kind of vulnerability is that it can execute commands and programs on any server in the browser through the URL address, thus causing security problems. For example, Allaire jrun 2.3 remote execution arbitrary command vulnerability and IPlanet web server 4 X has a buffer overflow vulnerability and so on.
Example: enter the following URL address on Allaire’s jrun server 2.3 http://jrun:8000/servlet/jsp/../../path/sample.txt , you can access files outside the web directory. If it is an EXE file, it may cause execution.

Reason: 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. The target host uses this vulnerability to request a file generated by user input, which will seriously threaten the security of the target host system.

Solution: install the latest patch.

III. other categories

The scope of these categories is a little large. They can include vulnerabilities in databases such as SQL server, Oracle and DB2, as well as vulnerabilities in operating systems such as WindowsNT / 2000 and Linu. The vulnerabilities of these things can be said to be fatal. For example, using some vulnerabilities of Linux can easily obtain the administrator’s permission to remotely control the server and obtain the full control permission of the system. In this way, it is much easier to obtain JSP source code or destroy the server than to step on an ant.

IV. summary of the full text

It can be seen from the above that JSP, like ASP, still has many security problems. Objectively speaking, it is impossible for the developers of server software to find all the bugs in the system in the internal test. Even after the software is released, the vulnerabilities found will only be a small part of them, and there will be new security problems in the future, so we must be vigilant at all times, And pay attention to the security of your website.

A good suggestion is to read more security articles. These security articles generally have detailed information, such as the version number of the software, the cause of vulnerabilities, etc. the most important thing is that they are also accompanied by a 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 use, and get the latest patches from there. What’s better is Microsoft’s site. Security announcements and patches are particularly timely.

Finally, I want to use one sentence as the end of the full text: an excellent hacker is not necessarily a good JSP programmer, but an excellent JSP programmer must be a good quasi hacker.

Which methods can realize the application security of java servlet and JSP?

A web application can have a variety of resources, and often many sensitive information is transmitted on the open network without protection measures. In this environment, in fact, many web applications have a certain degree of security requirements. Most servlet containers have a clear mechanism and structure to meet this security requirement. Although the details of guarantee and execution may be different, they all have the following characteristics:

1. Authentication: a mechanism by which communication entities verify each other’s behavior with a clear identity.
2. Access control for resources: for a group of users, some operations on the database are limited, or a mechanism that emphasizes the availability, integrity or confidentiality of some programs.
3. Data integrity: a mechanism to ensure that data is not modified by a third party during transmission.
4. Confidentiality or data privacy: a mechanism to ensure that data is only used by authorized users and can be safely transmitted.

Java servlet and security in JSP are realized in the following ways:

I. declarative security

Declarative security refers to expressing the security structure of an application, including roles, access control, and authentication required by the external form of an application. Publishing descriptors in web applications is a major tool for implementing declarative security.

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

II. Programmatic security

When declarative security cannot fully express the security model of an application, you can use programmatic security. Programmatic security includes the following methods of the HttpServletRequest interface:

The getremoteuser method returns the user name authenticated by the client. Isuserinrole asks the 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 let the servlet complete some logical judgments according to the logical role of the remote user. It also allows the servlet to determine the primary name of the current user. If getremoteuser returns null (which means no user is authenticated), isuserinrole always returns false and getuserprinciple always returns null.

III. roles

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

A servlet container can perform some description or programming security for rules, which are related to the requirements entered by calling the security attributes of these principals. For example:

1. When the deployer maps a security role to a user group in the operating environment, the user group to which the calling principle belongs will be obtained from the security attribute. If the user group of the principle matches the user group in the operating environment, the principle is a security role.
2. When the deployer maps a security role to a principle name in the security policy domain, the calling principle name is extracted from the security attribute. If the two are the same, the calling principle is safe.

IV. authentication

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

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

V. HTTP basic authentication

HTTP basic authentication is an authentication 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, in which the user is authenticated. Note: the realm string of the basic authentication mechanism does not necessarily reflect any security policy domain. The web client gets these user names and passwords and passes them to the web server. The web server then authenticates these users in a specific domain.

Because the password is transmitted using a 64 bit code, and the destination server does not verify, basic authentication is not a secure authentication protocol. However, some additional protections, such as using a secure transport mechanism (HTTPS) or using security measures at the network layer, can solve some problems.

Vi. http digest authentication

Like http digest authentication, http digest authentication authenticates a user based on user name and password. However, the transmission of password is in the form of encryption, which is much safer than the 64 bit encoding used in basic authentication. This method is not as secure as the personal key scheme of HTTPS client authentication. Since digest authentication is not widely used at present, servlet containers do not require it to be supported, but are encouraged to support 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 (PKC). At present, PKCs are useful in e-commerce applications. Servlet containers that do not adapt to J2EE do not require HTTPS protocol support.

VIII. Server tracking of authentication information

Just like the security identity mapped in the role, the running environment is the description of the environment rather than the description of the application.

1. Create a login mechanism and policy in the publishing environment of web application.
2. For applications published in the same container, the same authentication information can be used to represent the principal of these applications.
3. Require users to re authenticate only when passing the security policy domain.

Therefore, a servlet container requires that the verification information be tracked in the container layer, not in the application layer. Allow an authenticated user to reject an application that uses other resources, which are managed through a container restricted by the same security identity.

Recommended Today

The difference between Z-index: 0 and Z-index: Auto in CSS

Recently, in the process of learning cascading context, I had a question about the difference between Z-index 0 and auto, so I went to Baidu to check the information. Found some problems, combined with their own practice (experiment?) Sorted out this note. Corrigendum When checking the data, we found a saying that if the Z-index […]