Back to list
Has anyone ever exploited these Websphere (WAS) Weaknesses, If so How ? Can anyone Elaborate ?
Sep 21 2004 04:00AM
bob (bobhome dslextreme com)
9. Secure Every Layer of the Application
All too often, Web applications are deployed with some degree of
(home-grown or WAS-based) at the servlet layer, but other layers of the
application are left unsecured. This is usually due to the false
that only servlets need to be secured because they're the front door to
For example, developers often assume that EJBs don't need to be secured,
this assumption is dangerously wrong. An intruder can bypass the servlet
interfaces and go directly to the EJB layer and wreak havoc if you have
security enforcement at that layer. This is easy to do with available
IDEs that can introspect running EJBs, obtain their metadata, and
dynamically create test clients. WebSphere Studio is capable of this,
developers see this functionality every day when they use the integrated
Often, the first reaction to this problem is to secure EJBs via some
means - perhaps by marking them accessible to all authenticated users.
depending on the registry, "all authenticated users" might be every
in a company. Some administrators take this a step further and restrict
access to members of a certain group that means roughly "anyone that can
access this application." That's better, but it's usually not
everyone that can access the application shouldn't necessarily be able
perform all the operations in the application.
4. Don't Serve Servlets by Class Name
Servlets can be served by class name or via a normal URL alias.
applications choose the latter. That is, developers define a precise
from each URL to each servlet class in the web.xml file by hand or using
of the various WAS development tools.
However, WAS also lets you serve servlets by class name. Instead of
a mapping for each servlet, a single generic URL (such as /servlet)
all servlets. The component of the path after the base is assumed by WAS
be the class name for the servlet. For example,
/servlet/com.ibm.sample.MyServlet refers to the servlet class
Serving servlets by class name is accomplished by setting the
serveServletsByClassnameEnabled property to true in the ibm-web-ext.xmi
or by using the Application Assembly Tool (AAT) and checking "Serve
by classname" on the IBM Extensions tab of the WAR view. Do not enable
WAS feature. This feature makes it possible for anyone who knows the
any servlet to invoke it directly. Even if your servlet URLs are
attacker may be able to bypass the normal WAS URL-based security.
depending on the classloader structure, an attacker may be able to
servlets outside of your Web application.
[ reply ]
Copyright 2010, SecurityFocus