[OWASP-ESAPI] Hiding errors / CSRF token
davy.tielens at gmail.com
Thu Nov 27 05:43:08 EST 2008
Thanks for the fast and good replies!
I know it's possible to trap uncached errors with Java frameworks but it
would be nice to see a possiblity within ESAPI to do the same, just so an
application can completly rely on ESAPI to handle security. Doing this will
add up to the security provided against OWASP top ten - A6 - Information
Leakage and Improper Error Handling. But for now I'll try to implement
it in the ESAPI filter, like Jeff recommended.
Concerning the CSRF-token, it might indeed be overkill to add it to every
request, but I like to keep my applications as safe as possible. When using
ESAPI we may presume that there are no XSS flaws in the web-app and the
connection is secured by SSL so stealing the token would be very difficult,
but I'm mostly afraid of the social engineering skills of the modern day
attackers. CSRF is an attack often based on social engineering, only
providing a session based CSRF-token may not be sufficient for web-apps that
require a maximum of security. Call it paranoid.. but I can't bare it to
know there are still ways to attack the web-app even though the attack would
be quite impossible to perform.
It's seems the only solution to use an unique token each request
and maintain a good usability is to keep a stack. I like the idea of Linden
to keep track of a view state a lot, but I'm afraid this will result in
(maybe) unnecessary development complexity.
2008/11/26 Jim Manico <jim.manico at aspectsecurity.com>
> 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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-ESAPI