Has any decision been made on how the original poster will do this?
As I read through the various responses, while you can always argue certain structures are better, it's simply not true that if you create messy/insecure JSPs, you'll somehow create clean/secure servlets. Any error you would make in a JSP you'd make for sure in a servlet. Again, JSPs are servlets. You either protect requests coming in or not. You can play with or hack parameters being sent to a servlet just as you can to a JSP.
For sure, if you go through a servlet controller that does the user login checks first before forwarding, that can make sense to concentrate the requests, and JSPs would just be coded to stop processing (or redirect to a login page, or return an error status) if it doesn't have a session/request parameter added by the servlet that did the authorization.
You can put all parameter checking into such a servlet, but that seems not much better than having each servlet/JSP do parameter checking for those it makes use of (if this were a known good, then we'd have just one big servlet that does everything rather than dividing the work among lots of them). It seems that if you have JSPs, you'll want those to be checking params they expect (and safely ignore those you don't expect, or report them, or produce an error, whatever it is you expect to do when you see bad params come in).
It's unclear how direct access to a JSP is less secure than a servlet that will route requests to all of those same JSPs, other than your JSPs can somehow progress without caring who the authenticated user is. In the end, a JSP typically doesn't just care that you are authenticated, but who exactly you are as your user account is sure to have permissions associated with it and will vary its processing based on the user.
Are there known exploits of direct JSP access that is shown to be solved by putting all JSPs under WEB-INF?
Also, if server identification is so bad (it does seem to make it a bit easier to look for known exploits), why does Tomcat not block reporting anything about itself as the default? I can't imagine there are many deployments that prefer to be insecure so that they can provide Tomcat versioning info or the like. I mean, how many deployments need the Tomcat version info returned as they would know what version they are because they installed it.
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
