IBM WebSphere V5.0 Security - CGISecurity

Struts supports multiple mechanisms to map URIs for different actions; there are
two common approaches to define the URIs that will be processed by the
controller servlet - prefix matching and extension matching.
►
►
Prefix matching means that you want all URIs that start with a particular value
to be passed to this servlet, for example:
http://www.xyz.com/myapp/execute/myaction.
Extension mapping, on the other hand, matches request URIs to the action
servlet based on the fact that the URI ends with a period followed by a
defined set of characters. For example, the JSP processing servlet is mapped
to the *.jsp pattern so that it is called to process every JSP page that is
requested. In the case of Struts, we can map actions to the .do extension, that
implies, “to do something”; the URL looks like the following:
http://www.xyz.com/myapp/myaction.do
In any case, the actions are differentiated based on URIs, although only one
servlet performs the action. You have to make sure that you protect all the
required URIs for your application for all the actions with Struts. Just because
you will only have only one servlet mapping, this does not mean you only have to
set up one constraint. The only difficulty with Struts and with these approaches is
that you have to design and administer your security constraints for your Web
application very carefully, just as in any other case of security design. It is easy
not to secure or to set wrong access control to a sensitive resource and leave a
security hole in your application.
You can also protect your resources based on URL patterns using a security
reverse proxy in your infrastructure, for example via Tivoli Access Manager’s
WebSEAL.
Page expiration
This is a useful tip that you might want to keep in mind. The pages that are
served from application servers are cached at least on the client side, regardless
of whether the resource was secured or not.
It will be a problem in a live system, where sensitive information can be found in
the cache.
It is definitely a problem during development, when security settings were
changed for the Web module but the Web browser is still showing the pages from
the cache without going out to the server and getting the latest content, so that
no authentication or authorization check is performed. In this case, you can
simply set your browser to not cache pages and always send a request.
Chapter 4. Securing Web components 71