tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Niyazov <niya...@solni.law.columbia.edu>
Subject Re: request for suggestions on how to secure a web application....
Date Wed, 25 Jul 2001 17:58:41 GMT
I'm not sure whether it'll work for you but you can assert current session on 
each jsp page that you want to protect  (assuming you store user login info in 
the session) and throw an exception in case the object is not found in the 
session, then the exception can be caught by an error jsp page. 

hth

                                      - Boris


>
>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.
>
>
>
>
>
>
>
>
>
>
>
>


Mime
View raw message