[OWASP-ESAPI] Hiding errors / CSRF token

Jim Manico jim.manico at aspectsecurity.com
Wed Nov 26 15:10:48 EST 2008


Davy,

 

Jeff is right on in regards to "Or you could use the JavaEE mechanism
and put a handler for Throwable in web.xml that directs to a generic
JSP."

 

Also, Java frameworks take this concept one step further than base J2EE.
For example, this is one way to trap uncaught errors in Struts 1.3.10:

 

      <global-exceptions>

       <exception 

           type="java.lang.Exception"

           key="error.input" 

           handler="com.somecompany.actions.JSPErrorHandler"

           path="/WEB-INF/jsp/common/error.jsp"/>

      </global-exceptions>

 

Where JSPErrorHandler is our custom handler.

 

-    Jim

 

From: owasp-esapi-bounces at lists.owasp.org
[mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Jeff Williams
Sent: Wednesday, November 26, 2008 10:07 AM
To: 'Davy Tielens'; owasp-esapi at lists.owasp.org
Subject: Re: [OWASP-ESAPI] Hiding errors / CSRF token

 

Hi Davy,

I've been experimenting with this project for a couple of weeks and in
my opinion I must say this is a wonderful project. There is a great need
for projects like this because most developers don't know much about
security but with the quality code ESAPI provides even those developers
can produce very secure web-applications. 

Thanks for the nice note!

After implementing ESAPI into a project I sometimes got uncatched
exceptions and stacktraces (developer's fault, not ESAPI) while running
my application. These stacktraces where showed in the client's browser,
providing a lot of information to possible attackers. I was wondering if
it is possible to hide these errors from the user using ESAPI. Maybe by
redirecting users to a default error page which could be declared in the
ESAPI.properties file? 

As a design philosophy, ESAPI does not try to implement web application
framework features like this.  Instead, ESAPI sticks to fundamental
security mechanisms that can be used by all frameworks.  You could
certainly do this in your implementation of the ESAPI filter by catching
all Throwables.  Or you could use the JavaEE mechanism and put a handler
for Throwable in web.xml that directs to a generic JSP.

An other question I have is concerning the CSRF-token. When using an
unique CSRF-token each request it's not possible anymore to use the
browsers reload, back and forward button. Is it possible to use the
unique token and still be able to use those buttons? I was thinking to
save the previous tokens on a session, but maybe this could be to memory
consuming when visiting many pages? An other option, which I'm currently
using is to use a unique CSRF-token each session, but this reduces the
security of the application because the token could be stolen and
misused during a session. Any opinions/tips?

The default mode is to use a per-session CSRF token. There are utility
methods in HTTPUtilities for this and your ESAPIFilter might be the
place to verify them (or in your business functions). There's not a huge
advantage to doing it on every request.  If you really want to do this,
you could save the last 5 tokens or something.

Thanks!

--Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20081126/046d6006/attachment.html 


More information about the OWASP-ESAPI mailing list