Jing Zhou wrote:
The following is my experience about the subject over the years and also includes what I learned so far.
What is the best practice for the security checking with the MVC design pattern? Over the years, I learned that the Struts developers have been using the following ideas for the security checking as the best practice.
1) No one has direct access to any JSP pages in the web applications.
Sorry just to pick out one point from your email but I always see people saying this about protecting their JSPs.
I always wonder why, because not one of my JSPs would run without an error if they were accessed directly, because they all need either a form bean or lists or arrays for dropdowns and so on.
From a management point of view, the security is more a policyproblem than implementation problem. If you have two doors in your building that are exposed to outsiders and you trust the locks in them, that is fine.
When you have 20,000 doors (the JSP pages) in your building (web apps) that are exposed to *outsiders* (they could be your internal employees), and over the years you asked 20 independent consulting teams to fix problems in some of the doors, your confident level on the security of your building will drop.
That is one of the reasons you should ensure no one has direct access to your JSP pages *uniformly*. What we do for web applications is that we partition the resources into two categories: document oriented resources and application oriented resources. We let the application oriented resources (JSP pages for web applications) subject to rule one and document oriented resources (static files, Model 1 JSP pages for read only purpose) subject to the security constraints. With such a partition, we could avoid the situations where someone, no matter he is a outsider or internal employee, could access directly to the application oriented resources.
Is there some security hole that hackers can exploit if they find a valid JSP url, even if it returns a 404?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

