It is never a good idea for a web application to attempt to shut down the application container. A call to a termination method is probably part of leftover debug code or code imported from a non-J2EE application.

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

The most common example of forgotten debug code is a main() method appearing in a web application. Although this is an acceptable practice during product development, classes that are part of a production J2EE application should not define a main().

A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application.

In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface.

Example 1: The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

The J2EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues, including:

- In-band versus out-of-band signaling

- Compatibility between protocol versions

- Channel security

- Error handling

- Network constraints (firewalls)

- Session management

Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems.

Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers.

Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors.

Most web applications use a session identifier to uniquely identify users, which is typically stored in a cookie and transmitted transparently between the server and the web browser.


Applications that do not store session identifiers in cookies sometimes transmit them as an HTTP request parameter or as part of the URL. Accepting session identifiers specified in URLs makes it easy for attackers to perform Session Fixation attacks.

Placing session identifiers in URLs can also increase the chances of successful Session Hijacking attacks against the application. Session Hijacking occurs when an attacker takes control of a victim's active session or session identifier. It is common practice for web servers, application servers, and web proxies to store requested URLs. If session identifiers are included in URLs, they are also logged. Increasing the number of places session identifiers are viewed and stored increases the chances they will be compromised by an attacker.

If you are using Tomcat to perform authentication, the Tomcat deployment descriptor file specifies a "Realm" used for authentication. It looks like the following:

Example 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

This Realm tag takes an optional attribute called debug, which indicates the log level. The higher the number, the more verbose the log messages. If the debug level is set too high, Tomcat will write all usernames and passwords in plain text to the log file. The cutoff for debugging messages related to Tomcat's JAASRealm is 3 (3 or greater is bad, 2 or less is okay), but this cutoff may vary for the other types of realms that Tomcat provides.

Directly accessing Java Server Pages (JSPs) in applications built using web frameworks, such as Struts or Spring, that use actions or servlets to delegate requests to JSPs can result in unhandled exceptions and system information leaks. Poorly implemented or configured application servers have been co-opted into leaking source code details using specially crafted requests, such as http://host/page.jsp%00 or http://host/page.js%2570. Even worse, if an application permits users to upload arbitrary files, attackers may use this mechanism to upload malicious code in the form of a JSP and request the uploaded page to cause the malicious code to execute on the server.

Example 1: The following example shows a poorly constructed security constraint that explicitly allows direct access to JSPs with a '*' in the role name, which indicates that all users are allowed access the corresponding web resources.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

Duplicate security roles serve no purpose since only the last definition of a given security role will be applied.
Example 1: The entry from a web.xml file defines two admin roles.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

Duplicate servlet mappings serve no purpose since only the last entry will be applied when the same URL pattern is used in multiple servlet mappings.

Example 1: In the following example, the URL pattern /servletA/* is used in two different servlet mappings.

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

Multiple URL patterns that map to a single Servlet could be a sign that the Servlet performs too many functions.

Example 1: The following example maps five URL patterns to a single Servlet.

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

The longer a session stays open, the larger the window of opportunity an attacker has to compromise user accounts. While a session remains active, an attacker may be able to brute-force a user's password, crack a user's wireless encryption key, or commandeer a session from an open browser. Longer session timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created.

Example 1: If the session timeout is zero or less than zero, the session never expires. The following example shows a session timeout set to -1, which will cause the session to remain active indefinitely.

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

The <session-timeout> tag defines the default session timeout interval for all sessions in the web application. If the <session-timeout> tag is missing, it is left to the container to set the default timeout.

When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL.

There are three common ways for SSL to be bypassed:

- A user manually enters URL and types "HTTP" rather than "HTTPS".

- Attackers intentionally send a user to an insecure URL.

- A programmer erroneously creates a relative link to a page in the application, failing to switch from HTTP to HTTPS. (This is particularly easy to do when the link moves between public and secured areas on a web site.)

The WebLogic deployment descriptor should specify a session identifier length of at least 24 bytes. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, he can take over the user's session. The remainder of this explanation will detail a back-of-the-envelope justification for a 24-byte session identifier.

The session identifier is composed of a pseudorandom selection of the 62 alphanumeric characters, which means that if the string were composed in a truly random fashion each byte could yield a maximum of 6 bits of entropy.

The expected number of seconds required to guess a valid session identifier is given by the equation:

(2^B+1) / (2*A*S)

Where:

- B is the number of bits of entropy in the session identifier.

- A is the number of guesses an attacker may try each second.

- S is the number of valid session identifiers that are valid and available to be guessed at any given time.

The number of bits of entropy in the session identifier is always less than the total number of bits in the session identifier. For example, if session identifiers were provided in ascending order, there would be close to zero bits of entropy in the session identifier no matter the identifier's length. Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier. For realistic identifier lengths this is possible, though perhaps optimistic.

If attackers use a botnet with hundreds or thousands of drone computers, it is reasonable to assume that they could attempt tens of thousands of guesses per second. If the web site in question is large and popular, a high volume of guessing might go unnoticed for some time.

A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.)

With a 64-bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker may try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes.

Now assume a 128-bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

Working backwards from bits to bytes, now, the session identifier must be 128/6, which yields approximately 21 bytes. Furthermore, empirical testing has demonstrated that the first three bytes of the session identifier do not appear to be randomly generated, which means to achieve our desired 64 bits of entropy we need to configure WebLogic to use a session identifier 24 bytes in length.

A missing or duplicate servlet name in web.xml is an error. Every Servlet should have a unique name (servlet-name) and a corresponding mapping (servlet-mapping).

Example 1: The following entry from web.xml shows several erroneous servlet definitions.

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

These errors may cause an unintentional denial of access to the Servlet.

The <login-config> element is used to configure how users authenticate to an application. A missing authentication method means the application does not know how to apply authorization constraints since no one can log in. The authentication method is specified using the <auth-method> tag, which is a child of <login-config>.

There are four authentication methods: BASIC, FORM, DIGEST, and CLIENT_CERT.

BASIC denotes HTTP Basic authentication.
FORM denotes Form-based authentication.
DIGEST is like BASIC authentication; however, in DIGEST the password is encrypted.
CLIENT_CERT requires that clients have Public Key Certificates and use SSL/TLS.

Example 1: The following configuration does not specify a login configuration.

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

web.xml security constraints are typically used for role based access control, but the optional user-data-constraint element specifies a transport guarantee that prevents content from being transmitted insecurely.

Within the <user-data-constraint> tag, the <transport-guarantee> tag defines how communication should be handled. There are three levels of transport guarantee:

1) NONE means that the application does not require any transport guarantees.
2) INTEGRAL means that the application requires that data sent between the client and server be sent in such a way that it cannot be changed in transit.
3) CONFIDENTIAL means that the application requires that data be transmitted in a fashion that prevents other entities from observing the contents of the transmission.



In most circumstances, the use of INTEGRAL or CONFIDENTIAL means that SSL/TLS is required. If the <user-data-constraint> and <transport-guarantee> tags are omitted, the transport guarantee defaults to NONE.

Example 1: The following security constraint does not specify a transport guarantee.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

Every filter mapping must correspond to a valid filter definition in order for it to be applied.

Example 1: The following example shows a filter mapping that references the non-existent filter AuthenticationFilter. Because the definition is missing, the filter AuthenticationFilter will not be applied to the designated URL pattern /secure/* and might cause a runtime exception.

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>