How to "really" seal/secure directories or files with Tomcat?

[mech <me...@rz.fh-augsburg.de>]

Hi,

I was wondering about a behaviour of Tomcat that allows to include
content that is in a directory I have set an <security constraint> for.
Finally I had to understand that this weird thing is even servlet spec
2.3/2.4 conform:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4374

So actually "declarative security" is a bit like "obscurity" in my eyes!


If I can simply place a jsp file outside any security constraint and put
<jsp:include page="/protected/secret_content.html"/> inside, I can
bypass any container managed security for this webcontext and this is
even fine according the servlet spec 2.4 (SRV.12.2)!

For static html files you couldn't even use programmatic security, if
you decided to secure everything manually :-(

Does anyone have a idea how to seal a directory with Tomcat in the way
of Apache's .htaccess files where "secure" means "secure" and not
"secure, until you grab the content with <forward> and <include>"?

At least you can't jump out of "your" webapp with include/forward, thus
not possible to bypass all security settings of other people's webapps
if you use e.g. a "shared" Tomcat server. ( had to try this before I
could sleep again ;-) ...what if cross-context=true?)

Thanks for any ideas!
Michael





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

session id's really unique?

[shawn <ja...@koyuru.com>]

If I use RequestDispatcher.forward(request, response) to another context
am I running the risk of session id conflicts?  

I mean if a session Id is given in one context, another context is
restarted and the java.security.SecureRandom is re-initialized for that
webapp, then it would seem possible that newly generated sessions in the
second context could match the previosly generated session id that was
transferred from the first context.

I doubt I know as much as many on this list, but that is something that
I wondered about.

Shawn

PS  I'm relying on potentially outdated info from a list that was posted
in response to this topic.

 >Tomcat 4 uses an instance of java.security.SecureRandom to generate
> session identifiers for a particular session.  The instance is initialized
> the first time (after Tomcat is started, or after a webapp is restarted)
> that a session identifier is requested.
> 

....
> More seriously, it is *you* as the application developer that is deciding
> whether or not to execute the RequestDispatcher.include() or
> RequestDispatcher.forward() call -- it's not the container.  It is totally
> up to *you* to decide whether or not this is allowed, because *you* wrote
> the app.
> 
 yes I did but will the sessions tranfer uniquely?


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: How to "really" seal/secure directories or files with Tomcat?

["Craig R. McClanahan" <cr...@apache.org>]

On Sat, 28 Dec 2002, mech wrote:

> Date: Sat, 28 Dec 2002 14:04:50 +0100
> From: mech <me...@rz.fh-augsburg.de>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
>      mech@informatik.fh-augsburg.de
> To: tomcat-user@jakarta.apache.org
> Subject: How to "really" seal/secure directories or files with Tomcat?
>
> Hi,
>
> I was wondering about a behaviour of Tomcat that allows to include
> content that is in a directory I have set an <security constraint> for.
> Finally I had to understand that this weird thing is even servlet spec
> 2.3/2.4 conform:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4374
>
> So actually "declarative security" is a bit like "obscurity" in my eyes!
>
>
> If I can simply place a jsp file outside any security constraint and put
> <jsp:include page="/protected/secret_content.html"/> inside, I can
> bypass any container managed security for this webcontext and this is
> even fine according the servlet spec 2.4 (SRV.12.2)!
>

If this is the only way you, as the application developer, can think of to
bypass the security constraints in web.xml file, you're working to hard.
Why not just comment them out? :-)

More seriously, it is *you* as the application developer that is deciding
whether or not to execute the RequestDispatcher.include() or
RequestDispatcher.forward() call -- it's not the container.  It is totally
up to *you* to decide whether or not this is allowed, because *you* wrote
the app.

> For static html files you couldn't even use programmatic security, if
> you decided to secure everything manually :-(
>

As above, that's only true for static resources that are merged via
RequestDispatcher.include().  Security constraints are enforced on
original requests for static resources in a protected durectory.

> Does anyone have a idea how to seal a directory with Tomcat in the way
> of Apache's .htaccess files where "secure" means "secure" and not
> "secure, until you grab the content with <forward> and <include>"?
>

In Servlet 2.4 you can install a filter that matches "/*", and *is*
invoked on RequestDispatcher calls.  In such a filter, you can call
request.isUserInRole() and enforce your own checks if you want to.

> At least you can't jump out of "your" webapp with include/forward, thus
> not possible to bypass all security settings of other people's webapps
> if you use e.g. a "shared" Tomcat server. ( had to try this before I
> could sleep again ;-) ...what if cross-context=true?)
>

Set crossContext to false and nobody will be able to do this.  It's one of
the reasons that cross-context request dispatchers are able to be turned
off.

> Thanks for any ideas!
> Michael
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>