InfoCenter Home > 4.2.1.2.3.1: Avoiding the security risks of invoking servlets by class nameAnyone enabling the Invoker servlet to serve servlets by their class names Anyone enabling the "serve files by class name" function in WebSphere Application Server, should take steps to avoid potential security risks. The administrator should remain aware of each and every servlet class placed in the classpath of an application, even if the servlets are to be invoked by their classnames.
Protecting servletsTo protect each servlet, the administrator needs to:
Also, the administrator needs to secure the Invoker servlet itself. DetailsWebSphere security is based on defining, and then securing, URIs (known as Web resources) for servlets. This allows an administrator to apply different security levels to different paths for accessing the same servlet. Also, Web resources are logical designations that are not guaranteed to match servlet class names. For these reasons, actual class names are irrelevant to WebSphere security unless you explicitly specify that you want to protect the path for invoking a servlet by its class name. When a Web application allows users to invoke servlets by class name, the administrator is able to drop servlets into a Web application without having to explicitly define them in WebSphere systems administration. Suppose that the WebSphere administrator drops in a servlet class to be invoked by its class name. Even if a servlet corresponding to the same class name is defined and protected, users will be able to invoke the servlet by class name without any security checks. (The exception is if the administrator has created a Web resource corresponding to the servlet class name, as described in the above steps). Undefined servlets remain unprotected unless steps are taken to assign secure Web resources to them based on their class names.
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
|