Security issues of JSP and Servlet applications

I. Overview

As network programming becomes more and more convenient, the system functions become more and more powerful, and the security is exponentially reduced. This may be the misfortune and sorrow of network programming. WWW is flourishing in various dynamic content generation environments. Their design goal is to give developers more strength and convenience to end users. Because of this, system designers and developers must clearly consider security issues as a factor, and it is difficult to pursue regret afterwards.

From a security perspective, the weakness of the server WWW application comes from a variety of interaction capabilities and transmission channels. They are tools that attackers can directly use to influence the system. When attackers search for and exploit system security vulnerabilities, they always put pressure on the system. The general defense policy against all these attacks is the so-called input verification.
At the same level, there are two major design errors that cause security problems:
◆ Poor access control and
◆ Make implicit assumptions about the deployment environment.

In the security literature, there are many in-depth analyses on access control issues. Here we will discuss the security management issues on the underlying implementation code and configuration. The environment discussed is JSP. In other words, we will discuss how malicious user input disguise itself and various methods to change the predefined behavior of applications, and how to check the legitimacy of input and reduce undesirable detection of information and application interfaces.

Ii. JSP Overview

JSP technology allows Java code logic to be embedded into HTML and XML documents, which facilitates the creation and management of dynamic WWW content. The JSP page is pre-processed by the JSP Engine and converted to a Java Servlet. If a request to the JSP page appears, the Web server uses the Servlet output result as a response. Although JSP and Servlet are functionally equivalent, JSP and Servlet have the opposite dynamic content generation method: JSP embeds Java code into the document, instead of embedding documents in Java applications. To access external functions and reusable objects, JSP provides additional tags used to interact with the JavaBean Component. the syntax of these tags is similar to that of HTML tags. It is worth noting that the HTML syntax is a subset of the JSP syntax. A pure HTML document is a legal JSP page), but in turn it is not necessarily correct. In particular, to facilitate the dynamic generation of content and format, JSP allows other tags to be embedded within the tag. For example, the following is a valid JSP code:

As you can see later in this article, this structure increases the complexity of security issues. Compared with CGI, JSP has better performance and session management, that is, session state persistence. This is mainly implemented by using Java threads to process multiple servlets in the same process. CGI generally requires that a process be created and removed for each request.

Iii. Security Issues

Because access to server resources is completely open, insecure servlets converted from JSP pages may threaten any or all of the networks of servers, servers, and clients accessing the pages, or even use DDoS or worm distributed attacks, it may also affect the entire Internet. It is often assumed that Java, as a type of secure language with garbage collection capabilities and a Sandbox mechanism, can miraculously ensure software security. In fact, many low-level security problems that exist in other languages, such as buffering or heap overflow, rarely bring harm to Java programs. However, this does not mean that it is difficult for people to write insecure Java programs, especially for Servlet writing. Verifying input and controlling access to resources is always a concern. In addition, the architecture of JSP is quite complex, including many subsystems that work together. The interaction between these subsystems is often the root cause of security risks. In addition, although all JSP implementations are centered around Java, the JSP specification allows almost all other languages to assume this role. In this way, the security of these alternative languages must also be considered.

In short, there are many opportunities to generate security vulnerabilities in the JSP system. Next we will discuss the most common parts of them.

Iv. general questions about untrusted user input

Untrusted User Input) contains all User Input. User input comes from the client and can be sent to the server through many different channels, sometimes in disguise. User inputs provided for JSP and Servlet servers include but are not limited ):
◆ Parameter section of the request URL,
◆ Data submitted by HTML forms through POST or GET requests,
◆ The data temporarily saved on the client, that is, the Cookie ),
◆ Database query,
◆ Environment variables set by other processes.

The problem with user input is that they are explained by server applications, so attackers can control the vulnerable part of the server by modifying the input data. The vulnerable part of the server is often represented by some data access points, which are identified by the user's qualified word or obtained by executing an external program.

JSP can call local code stored in the library through JNI) and execute External commands. Class Runtime provides an exec () method. The exec () method treats its first parameter as a command line that needs to be executed in an independent process. If some parts of the command string must be obtained from user input, user input must be filtered first to ensure that the commands executed by the system and their parameters are both unexpected. Even if the command string does not have any relationship with user input, the necessary check is still required when executing the external command. In some cases, attackers may modify the environment variables of the server to affect the execution of External commands. For example, modify the path environment variable to point to a malicious program, which is disguised as the name of the program called by exec. To avoid this risk, it is a good habit to explicitly set environment variables before any external call. The specific setting method is as follows: In the exec () call, an array of environment variables is used as the second parameter, and the elements in the array must be in name = value format.

1. Java Servlets (JSP) Development Environment
2. Develop jsp http Server
3. Select JSP development tools
4. Servlet and JSP paths
5. Technical Points for transferring in JSP Servlet