IBM WebSphere V5.0 Security - CGISecurity

Struts supports multiple mechanisms to map URIs for different actions; there aretwo common approaches to define the URIs that will be processed by thecontroller servlet - prefix matching and extension matching.►►Prefix matching means that you want all URIs that start with a particular valueto 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 actionservlet based on the fact that the URI ends with a period followed by adefined set of characters. For example, the JSP processing servlet is mappedto the *.jsp pattern so that it is called to process every JSP page that isrequested. In the case of Struts, we can map actions to the .do extension, thatimplies, “to do something”; the URL looks like the following:http://www.xyz.com/myapp/myaction.doIn any case, the actions are differentiated based on URIs, although only oneservlet performs the action. You have to make sure that you protect all therequired URIs for your application for all the actions with Struts. Just becauseyou will only have only one servlet mapping, this does not mean you only have toset up one constraint. The only difficulty with Struts and with these approaches isthat you have to design and administer your security constraints for your Webapplication very carefully, just as in any other case of security design. It is easynot to secure or to set wrong access control to a sensitive resource and leave asecurity hole in your application.You can also protect your resources based on URL patterns using a securityreverse proxy in your infrastructure, for example via Tivoli Access Manager’sWebSEAL.Page expirationThis is a useful tip that you might want to keep in mind. The pages that areserved from application servers are cached at least on the client side, regardlessof whether the resource was secured or not.It will be a problem in a live system, where sensitive information can be found inthe cache.It is definitely a problem during development, when security settings werechanged for the Web module but the Web browser is still showing the pages fromthe cache without going out to the server and getting the latest content, so thatno authentication or authorization check is performed. In this case, you cansimply set your browser to not cache pages and always send a request.Chapter 4. Securing Web components 71