RE: request for suggestions on how to secure a web application... .

[Brigger Patrick <Pa...@GETABSTRACT.com>]

One simple solution, but works perfectly:

After the login process, save the login information in an object, for
instance a customer object.

session.putValue("customer", customer);

In your JSP page, read the customer object:

Customer customer = (Customer) session.getValue("customer");

Then do a check if the object has been initialized:

if (customer == null)
{
  redirect to login page. 
}
else
...

I usually included the return URL when I redirect to the login page so that
this page knows where to redirect back to.

Cheers,

Pat

-----Original Message-----
From: Peter Brandt-Erichsen [mailto:pbe@adsl.intergate.ca]
Sent: Mittwoch, 25. Juli 2001 09:51
To: tomcat-user@jakarta.apache.org
Subject: request for suggestions on how to secure a web application....


This posting is a request for suggestions on how best to 
secure a web application.

First my setup:

NT 4.0
Apache 1.3.12
Tomcat 3.2.1 (running behind Apache)
servlets 
jsp pages
static html pages
jdk1.3


Web-app directory structure:

webapps/my_context/
    /jsp/jsp_pages
    /web-inf/classes/my_servlets
    /web-inf/classes/beans/my_java_beans

My static html files reside under the apache 
document root.

For servlet access I am using session cookies, as specified in
the Java Servlet Spec, to authorize users. This works very 
well for my purposes.

My concern is protecting sensitive jsp and static
html pages.

How do I stop an unauthorized user from accessing a 
jsp or html resource directly?  ie: a back-door attack.  

For example, I am protecting my site with a login page, 
but if a user simply sidesteps the login and types
    
        http://my_domain/my_context/jsp/any_jsp_page

into his browser, he will get access to any jsp page 
that resides in the specified context. 

I have experimented with some different approaches:

1.  hide the jsp directory directly under the /web-inf 
directory and let Tomcat restrict access.

So I would have:

        /web-inf/classes/servlets
        /web-inf/jsp/jsp_pages

Then provide access to jsp pages only through a 
verification servlet, which can verify the user and
then forward the request to the correct resource. 

However, this is causing problems when I utilize a 
RequestDispatcher(path).forward(req, res)  or 
RequestDispatcher(path).include(req, res) 
instruction.

The path needs to start with a "/" and be relative to 
the context root, per the Java Servlet API docs, which makes 
it impossible(?) to provide a correct path, since my 
verification servlet, and hence the execution thread, 
is in /web-inf/classes. When I issue the forward or inlude, 
I need to provide a path that looks something like:

        /../jsp/jsp_page 

which is correctly making the JVM puke.


2. Utilize the apache rewrite module and have apache
rewrite all requests for http://my_domain/my_context/jsp/*.jsp
to my verification servlet. The verification servlet can then
do its thing and forward valid requests to the appropriate 
request. 

A hornet's nest of complexity here! and my nose tells
me this is the wrong path to take.


3. Thought a lot about utilizing the Tomcat API.

ie: RequestInterceptor, Virtual Host, Valves etc.

I found rudimentary information about what these
constructs are, but very little on how to use them.

So, I am kinda stumped :-(

I guess the next step would be to explore Basic or
Digest Authorization, but I was hoping there would be
a simpler way, that uses the power of servlets....

I would greatly welcome any and all suggestions....

Thank you, and keep up the great work.
The Tomcat effort rocks!

Peter


BTW, I anticipate that the Tomcat docs will improve greatly 
in the future, and I was greatly encouraged to see the 
effort being put into making a book, and the template forming
around v4.0

I would like to suggest a section on real world examples, 
using and programming the Tomcat API and the xml config 
files, like server.xml. 

For an example of what I mean, the documentation 
for the Apache mod_rewrite, written by Ralf S. Engelschall, 
has a section on practical solutions. 

http://httpd.apache.org/docs/mod/mod_rewrite.html

That's kinda what I mean.