[OWASP-ESAPI] Hiding errors / CSRF token
Linden.Darling at jds.net.au
Wed Nov 26 22:15:13 EST 2008
This is my first post to ESAPI list (hope I've done it right) however
have been following it since the start of the year. Am keen to get
involved with the development of ESAPI for PHP! Some opinions/ideas in
response to Davy Tielens email are below.
Date: Wed, 26 Nov 2008 12:46:53 +0200
From: Rogan Dawes <lists at dawes.za.net>
Subject: Re: [OWASP-ESAPI] Hiding errors / CSRF token
To: Davy Tielens <davy.tielens at gmail.com>
Cc: owasp-esapi at lists.owasp.org
Message-ID: <492D291D.4010504 at dawes.za.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Davy Tielens wrote:
>> 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.
Applying CSRF tokens to every URL within an application is typically
overkill. Sure, it's easier to apply it to everything, however can mar
the (non-malicious) user experience. CSRF is a major problem when an
action/change is made to some data based on the request, so it should be
applied where that occurs. Typically a business process within an
application will (should!) have a starting point at which a
data-changing action does not occur, if a request for a URL within the
business process does not contain the correct CSRF then serve the
starting point of that business process (e.g. when a user presses the
back button). This does allow any CSRF tokens served in the content of
the starting point page to be scrapped and used for a
sequenced-CSRF-attack, but is a neater solution than having a single
CSRF token per session and on every single page.
On top of this, tracking the "view state" of the User means you can kill
sessions that seem to have out-of-order requests (pressing 'BACK' button
on browser typically should not equate to an out-of-order request). And
User's shouldn't be making requests to a "view state" within a business
process without having followed the steps it takes to validly get to
that "view state".
Historically CSRF tokens are applied to POST requests, where going
"back" in the browser will also prompt for re-submission of POST values
- which is usually not desirable. Killing the session in this case would
be extremely annoying to legitimate Users, so redirecting to the start
of business process is a nicer thing to do.
>> Is it possible to use the
>> unique token and still be able to use those buttons? I was thinking
>> save the previous tokens on a session, but maybe this could be to
>> consuming when visiting many pages? An other option, which I'm
>> using is to use a unique CSRF-token each session, but this reduces
>> security of the application because the token could be stolen and
>> misused during a session. Any opinions/tips?
This could be done neatly in conjunction with tracking the User's "view
state" and with some thought about the number of times a User should be
allowed to go 'Back' when within a business process. Allowing Users to
have multiple "view states" complicates things here, in which case you
would need to save lots more 'last-view-state-CSRF-tokens'.
>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.
Date: Wed, 26 Nov 2008 10:06:37 -0500
From: "Jeff Williams" <jeff.williams at owasp.org>
Subject: Re: [OWASP-ESAPI] Hiding errors / CSRF token
To: "'Davy Tielens'" <davy.tielens at gmail.com>,
<owasp-esapi at lists.owasp.org>
Message-ID: <492d65e2.0e35640a.1b41.7224 at mx.google.com>
Content-Type: text/plain; charset="us-ascii"
I've been experimenting with this project for a couple of weeks and in
opinion I must say this is a wonderful project. There is a great need
projects like this because most developers don't know much about
but with the quality code ESAPI provides even those developers can
very secure web-applications.
Thanks for the nice note!
After implementing ESAPI into a project I sometimes got uncatched
and stacktraces (developer's fault, not ESAPI) while running my
These stacktraces where showed in the client's browser, providing a lot
information to possible attackers. I was wondering if it is possible to
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
mechanisms that can be used by all frameworks. You could certainly do
in your implementation of the ESAPI filter by catching all Throwables.
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
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
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
unique CSRF-token each session, but this reduces the security of the
application because the token could be stolen and misused during a
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
verify them (or in your business functions). There's not a huge
doing it on every request. If you really want to do this, you could
the last 5 tokens or something.
-------------- next part --------------
An HTML attachment was scrubbed...
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
End of OWASP-ESAPI Digest, Vol 14, Issue 7
More information about the OWASP-ESAPI