4.9 Runtime Restrictions for Web Components

4.9 Runtime Restrictions for Web Components

A number of programming restrictions must be followed in order to maintain portability of Web components ”servlets and JSP applications ”between containers, as well as to preserve security. Some of these restrictions can be enforced by the Web Container Provider; others are solely the responsibility of the Web Application Provider.

• Web components must not write to and depend on static fields but should instead use enterprise beans or databases. Writing to static fields can result in inconsistency in deployed applications, as some containers will run all instances of an application in a single Java virtual machine, whereas others will run the same application in multiple containers.

• Web Container Providers may limit the creation of threads. Therefore, Web component developers must not use java.lang.Thread objects, and thus multithreading, within their Web applications.

  One important aspect from a security perspective is the fact that a Web application's security context is typically maintained at the granularity of a thread. Managing the context per thread is implementation dependent; therefore, a Web application's security context will not be automatically tranferred when a new thread is created.

• J2SE Abstract Windowing Toolkit (AWT) functionality must not be used to interact with a keyboard or a display. Web components are intended to be server-side components that front end transactional components, and containers are designed to facilitate high-throughput transaction processing. As such, interaction with a keyboard or a display will interfere with these objectives. Therefore, containers do not support keyboard/display interactions.

• Web components are allowed to perform file read and write I/O operations via the java.io package, including reading and writing via java.io.FileDescriptor objects. That said, owing to inherent security risks in letting untrusted components write or even delete files from the file system, Web Container Providers may enforce certain restrictions. (For example, Web components may only read and write files under a directory that maps to the context root of the Web application to which they belong.) Deleting and executing files is forbidden, even though from a practical point of view, granting the permission to write to a file is implicitly equivalent to granting the permission to delete it.

• The network socket operations listen, accept, and multicast are not allowed. Although Web components are server objects, all inbound communication must be routed through the Web container. If a Web component were to become a server via listen and accept operations, it would interfere with the objective of being a server for Web client requests. Additionally, the security policy is likely to be violated, as all communication with a Web component, including authentication and authorization requests , is supposed to be routed through the Web container and its method- and role-based authorization mechanisms.

  A Web component is allowed to be a network client, making requests to other network applications. It may connect to enterprise beans via RMI-IIOP; other resource adapters, such as a database, or other legacy server environments that communicate over socket connections.

• The following operations are not allowed: obtaining a java.lang.ClassLoader , including the current ClassLoader ; setting the context ClassLoader and the SecurityManager ; creating a new SecurityManager ; stopping the JVM; changing the input, output, or error streams in java.lang.System ; setting network socket factories and URL stream handlers; starting, stopping, suspending, and resuming Threads ; or changing Thread names or priorities. These functions are reserved for use by the container. Modification of any of these would undermine both security and the container's stability.

  However, Web components are allowed to load native libraries. This flexbility is allowed for Web components to provide a Web front end to native applications.

• Security policy information in the container should not be interrogated or modified. This includes the java.security.Policy implementation. The container implements security and may use J2SE security mechanisms but may include mechanisms that are not part of J2SE. There is no guarantee that Web components using the J2SE APIs will get the correct or consistent information about the container's security policies. Interrogating the security policy can also create security exposures, particularly if the results of the interrogation were to be disseminated outside the container: for example, if they were sent to a Web client. This information would enable a malicious entity to better plan an attack against the container and/or enterprise.

• Web components should not be allowed to set system properties by calling System.setProperty() . Reading the value of a system property should instead be permitted.

The Web container can enforce some of the preceding programming model restrictions through the use of a J2SE security policy configuration. Such a policy configuration should unconditionally deny java.security.AllPermission , java.awt.AWTPermission , java.net.NetPermission , java.lang.reflect.ReflectPermission , java.security.SecurityPermission , and java.io.SerializablePermission and grant java.util.PropertyPermission "read", "*" , java.lang.RuntimePermission "queuePrintJob" and "loadLibrary.*" , java.net.SocketPermission "connect", "*" , and java.io.FilePermission "<<ALL FILES>>", "read, write" . These authorizations allow Web components to be portable. However, some containers may enforce further restrictions or may be lenient and allow for more permissions.