Security issues of JSP 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), and the discussion environment 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, compared with Servlet, JSP's dynamic content generation method is the opposite: 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 HTML syntax is a subset of JSP syntax (a pure HTML document is a legal JSP page), but it is not necessarily correct in turn. 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:
<A href = "<% = request. getRemoteUser () %>">
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 (session state persistence) mechanism. 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 Sandbox mechanisms, 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 actually 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 input provided for the JSP server includes (but is not limited ):
· Request URL parameters,
· Data submitted by HTML forms through POST or GET requests,
· Temporary data (Cookie) stored on the client ),
· 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 (through JNI) stored in the library 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.
Similar problems may occur when user input is used to identify any type of input/output stream opened by a program. Access to files, databases, or other network connections should not rely on unverified user input. In addition, it is unsafe to directly send user input to a stream. This is especially important for SQL queries. The following JSP code snippets accessing the jdbc api are insecure because attackers can embed characters that separate commands in the input they submit to execute Dangerous commands:
<% @ Page import = "java. SQL. *" %> <! -- Add some code to open the SQL Server connection --> <% Statement stmt = connection. getStatement (); String query = "SELECT * FROM USER_RECORDS where user =" + request. getParameter ("username"); ResultSet result = Statement.exe cuteQuery (query); %>
If username contains a semicolon, for example:
Http: // server/db. jsp? Username = joe; SELECT % 20 * % 20 FROM % 20SYSTEM_RECORDS
Some versions of SQL Server ignore the entire query, but some versions of SQL Server execute two commands. If the latter is used, attackers can access the database resources that are not eligible to be accessed (assuming that the Web server has access permissions ).
Appropriate input tests can prevent such problems.
V. input test
From a security perspective, the input validation includes a syntax check for data from external data sources (untrusted data sources, see the instructions above), and sometimes a semantic check. Depending on the importance of the application and other factors, the actions taken as the input test results may be one or more of the following:
· Ignore syntactic insecure components,
· Use secure code to replace insecure parts,
· Stop using the affected code,
· Report errors,
· Activate an intrusion monitoring system.
Input Validation can be performed in either of the following two modes: List insecure characters and reject them; define a set of secure characters, and then exclude and reject insecure characters. These two modes are called forward and reverse input filtering respectively. In general, forward input filtering is simpler and safer, because many times, it is not easy to list characters that may be misunderstood by server applications, client browsers, Web servers, and operating systems.
See the input validation example in the "attacks implemented by embedding tags" section below. This example demonstrates how to avoid misunderstanding of input content submitted by malicious means.
6. Sensitive data in GET requests and cookies
As defined in CGI, the simplest way to transmit request data from the client to the server is the GET request method. When using the GET request method, the input data is appended to the request URL in the following format:
URL [? Name = value [& name = value [&...]
Obviously, this encoding method is not suitable for transmitting sensitive data, because the entire URL and request string are usually transmitted in plaintext through the communication channel. All routing devices can record the same information as the server. To transmit sensitive data in customer requests, we should use the POST method and add a suitable encryption mechanism (for example, through SSL connection ). From the perspective of the JSP Engine, to a large extent, which transmission method is used is irrelevant because the two methods are the same.
During the development of WWW, Netscape introduced the concept of Cookie. Cookie is a small amount of information stored on the client by the server. The server extracts the information to maintain the session status or track the activity of the client browser. JSP provides an addCookie () method for the response implicit object, which is used to set the Cookie on the client. It provides a getCookie () method for the request () object to extract the Cookie content. Cookie is an instance of the javax. servlet. http. Cookie class. For two reasons, if sensitive data is stored in the Cookie, security is threatened: first, all the content of the Cookie is visible to the client; second, although browsers generally do not provide the ability to forge cookies, nothing can prevent users from responding to the server with completely forged cookies.
Generally, the information submitted by any client browser cannot be assumed to be absolutely secure.
7. Attacks implemented by embedding tags
The CERT Advisory CA-2000-02 describes how customers embed malicious HTML tags in requests. This problem is generally called the "cross site scripting" problem, but its name is not used properly because it is not only related to scripts, but also related to the cross site) there is no special relationship. However, when this name appears, the problem has not been widely known.
This attack usually contains a user-submitted pathological script or malicious HTML (or XML) tags, which the JSP Engine will introduce to dynamically generated pages. This attack may target other users or servers, but the latter is not common. Typical examples of cross site scripting attacks can be seen on Forum servers because these servers allow users to embed formatting tags in their own articles. Abuse tags are commonly used to EMBED code into pages, such as <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>. In addition, some tags may cause danger. In particular, <FORM> may be used to expose sensitive information to spoofed viewers. The following is an example of a request string containing a malicious flag:
Http: // server/jsp_script.jsp? Poster = evilhacker & message = <SCRIPT> evil_code </SCRIPT>
To prevent such problems, input check and output filtering are required. This type of check must be performed on the server and should not rely on client scripts (such as JavaScript), because nothing can prevent users from escaping from the client inspection process.
The following code snippet demonstrates how to check the embedded tag on the server:
<! -- HTML code ended --> <% String message = request. getParameter ("message"); message = message. replace ('<', '_'); message = message. replace ('>', '_'); message = message. replace ('"', '_'); message = message. replace (''', '_'); message = message. replace ('%', '_'); message = message. replace (';', '_'); message = message. replace (',' _ '); message = message. replace (')', '_'); message = message. replace ('&','_'); Message = message. replace ('+', '_'); %> <p> the message you submitted is: Since listing all invalid characters is more difficult, a safer way is to perform forward filtering, except for those characters that are indeed allowed to appear (for example, [A-Za-z0-9]), discard (or convert) All other characters.
8. About JavaBean
JSP can quickly and conveniently access reusable components (Java objects) on the JSP page according to a series of conventions described in the JavaBean specification ). Each JavaBean Component encapsulates data and functions that can be used independently without relying on the call environment. Bean contains data members (attributes) and uses the Get and Set methods to access standard APIs for these attributes.
To quickly Initialize all attributes of a specified Bean, JSP provides a shortcut, that is, a name = value pair is provided in the query string and matches the name of the target attribute. Consider the following example of using Bean (displayed in XML format ):
<Jsp: useBean id = "myBasket" class = "BasketBean"> <jsp: setProperty name = "myBasket" property = "*"/> <jsp: useBean> Note the wildcard "*" used in the setProperty method call. This symbol indicates that JSP sets the values of all attributes specified in the query string. The script is called as follows:
Http: // server/addToBasket. jsp? NewItem = ITEM0105342
Normally, the query string constructed by an HTML form is in this form. But the problem is that nothing can prevent users from setting the balance attribute:
Http: // server/addToBasket. jsp? NewItem = ITEM0105342 & balance = 0
When processing the <jsp: setProperty> tag on the page, the JSP Container maps this parameter to the balance attribute with the same name in the Bean and tries to set this attribute to 0.
To avoid this problem, JSP developers must implement certain security measures in the Bean Set and Get methods (Bean must implement Mandatory Access Control on attributes), while using <jsp: be cautious when using the setProperty> wildcard.
9. Implementation Vulnerabilities and source code security
No matter which JSP implementation, some of their versions will pose a dangerous security risk to the system at a certain stage, even if JSP developers follow the security programming conventions. For example, in a JRun version of Allaire, if the request URL contains the string ". jsp % 00 "is part of the JSP script extension. The server does not ignore null bytes and regards the page as a static non-JSP page. In this way, the server requests the operating system to open the page, but the null byte is ignored. The result is the source code of the JSP page rather than the execution result of the page.
Similarly, a Tomcat version has a security risk. As long as the request type is in the following format, attackers can see the source code of the JSP page:
Http: // server/page. js % 2570
The scam here is that % 25 is the URL encoded "%", while 70 is the hexadecimal value of "p. The Web server does not call the JSP processor (because the URL does not end with ". jsp"), but the static file processor tries to map the URL to the correct file name (decoding the URL again ).
In addition, many Web servers and JSP implementations carry demonstration scripts, which often contain security risks. Before deploying a server to a non-malicious environment (Internet), disabling access to all these scripts is secure.
In short, JSP developers should be clear about the current security risks on the platform they are developing. Subscribing to BUGTRAQ and the list of emails provided by all vendors is a good way to track such information.
Conclusion
JSP is the same as any other powerful technology. To ensure the security and reliability of the deployed system, you must be cautious when using JSP. In this article, we briefly discuss code and configuration-level security issues that often occur in JSP scripts, and propose suggestions to reduce the security risks.