On Thu, 3 Jul 2003, Adam Hardy wrote:
> Date: Thu, 03 Jul 2003 13:47:20 +0200 > From: Adam Hardy <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: Re: Webapp Security? > > Adam Hardy wrote: > > Marc wrote: > > > >> To protect your JSP, put them in a subdir of WEB-INF. Actions are > >> still able to redirect to those JSPs but they are not direct accessible. > >> > >> To protect your other files, just make a servlet and use path-mapping > >> like '/resources/*' to map all requests to this servlet. > > > > > > > > What kind of security breaches are JSPs susceptible to, once they > > protected by a security-constraint path mapping? > > what I mean is, are other files like HTML & style sheets & images > vulnerable? The reason people are concerned about putting JSP pages inside /WEB-INF is generally to avoid clients trying to access them directly (by typing a URL into the location bar); it is not really a security issue. In effect, the container provides an automatic security constraint that disallows ALL direct accesses from the client to anything under /WEB-INF. What you generally care about (from a security perspective) is ensuring that only authorized persons can perform dynamic actions on your web application. If you don't care who can do something, then don't protect it with a security constraint. The same goes for static content -- if the content is confidential to people that only have a particular role, then protect it with a security constraint that requires that role before allowing access. It doesn't matter whether the particular resource is implemented with JSP pages or ASP, or whether it's static or dynamic -- the key question is "should person X be able to access it". It is *generally* simpler to use container managed security for things like this, because you can declare the constraints declaratively in your web.xml file, and not have to enforce it with functional logic inside your app. But there are also going to be cases where your needs go beyond what standard container managed security provides -- the way you make a choice should start from understanding what you're trying to protect and from whom, before deciding how to protect it. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
