Has anyone ever exploited these Websphere (WAS) Weaknesses, If so How ? Can anyone Elaborate ?

["bob" <bobhome () dslextreme com>]

9. Secure Every Layer of the Application
All too often, Web applications are deployed with some degree of
security
(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
assumption
that only servlets need to be secured because they're the front door to
the
application.

For example, developers often assume that EJBs don't need to be secured,
but
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
no
security enforcement at that layer. This is easy to do with available
Java
IDEs that can introspect running EJBs, obtain their metadata, and
dynamically create test clients. WebSphere Studio is capable of this,
and
developers see this functionality every day when they use the integrated
test client.

Often, the first reaction to this problem is to secure EJBs via some
trivial
means - perhaps by marking them accessible to all authenticated users.
But,
depending on the registry, "all authenticated users" might be every
employee
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
sufficient, as
everyone that can access the application shouldn't necessarily be able
to
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.
Normally,
applications choose the latter. That is, developers define a precise
mapping
from each URL to each servlet class in the web.xml file by hand or using
one
of the various WAS development tools.

However, WAS also lets you serve servlets by class name. Instead of
defining
a mapping for each servlet, a single generic URL (such as /servlet)
serves
all servlets. The component of the path after the base is assumed by WAS
to
be the class name for the servlet. For example,
/servlet/com.ibm.sample.MyServlet refers to the servlet class
com.ibm.sample.MyServlet.

Serving servlets by class name is accomplished by setting the
serveServletsByClassnameEnabled property to true in the ibm-web-ext.xmi
file
or by using the Application Assembly Tool (AAT) and checking "Serve
servlets
by classname" on the IBM Extensions tab of the WAR view. Do not enable
this
WAS feature. This feature makes it possible for anyone who knows the
name of
any servlet to invoke it directly. Even if your servlet URLs are
secured, an
attacker may be able to bypass the normal WAS URL-based security.
Further,
depending on the classloader structure, an attacker may be able to
invoke
servlets outside of your Web application.