[OWASP-ESAPI] Hiding errors / CSRF token

Rogan Dawes lists at dawes.za.net
Wed Nov 26 05:46:53 EST 2008

Davy Tielens wrote:
> Hi,
> 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.
> 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?

Ideally, this could be caught by the ESAPI filter, although I don't know 
if that is possible.

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

No, this is a compromise that has to be made. Unfortunately, it is too 
complex to retain previous CSRF tokens, and associate them with the 
specific URL (and parameter set) that they apply to, and as you mention 
below, too memory intensive.

This approach also means that users that open multiple windows to the 
same app are also not supported.

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

Using per-session CSRF tokens is the default, I think, for the exact 
reason that it is least likely to break existing application paradigms.

If the CSRF token can be stolen and misused during a session, all bets 
are off anyway. There are two ways that this can be achieved:

1) Through XSS, in which case they could also extract the per-operation 
CSRF token if they wanted to.
2) Through network sniffing, in which case they can also extract the 
per-operation CSRF-token if they wanted to.


Rogan Dawes

More information about the OWASP-ESAPI mailing list