[OWASP-ESAPI] SecurityRequestWrapper

Jeff Williams jeff.williams at owasp.org
Fri Dec 4 11:45:41 EST 2009


Making it configurable makes sense. Now that you've got me thinking about
it, we should probably also address the access-control bypass problem with
forwards as well.  From the Java tutorial.

 

"Security constraints work only on the original request URI and not on calls
made throug a RequestDispatcher (which include <jsp:include> and
<jsp:forward>). Inside the application, it is assumed that the application
itself has complete access to all resources and would not forward a user
request unless it had decided that the requesting user also had access."

 

I've found open forwards in a number of apps over the years that allow
bypassing access control rules - including those in an external device like
a SiteMinder.  Would be nice to find a way to fix this problem elegantly.

 

--Jeff

 

 

From: Chris Schmidt [mailto:chrisisbeef at gmail.com] 
Sent: Thursday, December 03, 2009 10:49 AM
To: Jeff Williams
Cc: OWASP-ESAPI
Subject: Re: [OWASP-ESAPI] SecurityRequestWrapper

 

I can see a lot of situations where this makes sense, but what to do if you
need to do a server side forward to someplace that is publicly accessable? I
know in our codebase at work, we very frequently need to do this, and a 301
is not acceptable for SEO reasons? It seems like at minimum, this behavior
should be configurable. Perhaps a configuration option for the
SecurityWrapper so that multiple filters could be setup which have different
configurations?

 

Thoughts?

On Thu, Dec 3, 2009 at 4:07 AM, Jeff Williams <jeff.williams at owasp.org>
wrote:

This is intended to make sure that developers put resources inside web-inf
where they can't be force browsed to.

--Jeff







On Dec 3, 2009, at 1:46 AM, Chris Schmidt <chrisisbeef at gmail.com> wrote:

Is there a good reason that the getRequestDispatcher method in this
wrapper requires the path to begin with WEB-INF?

In my experience, this seems completely counter intuitive and actually
the opposite of what I would envision the overriden method to do.

I think this should instead be checking for traversal issues and
making sure the requested path does NOT start with WEB-INF but maybe I
am missing something?

Sent from my iPwn

_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20091204/2e54e696/attachment.html 


More information about the OWASP-ESAPI mailing list