tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Using CSRF prevention filter with session-timeout workflow resumption
Date Thu, 21 Nov 2019 16:20:23 GMT
> Mark,
> On 11/21/19 04:00, Mark Thomas wrote:
>>> All,
>>> The servlet spec defines the workflow for form-based
>>> authentication: if the client requests a protected resource, an
>>> authorization check is performed. If the user is unauthenticated,
>>> the login form is shown. Successful login allows the user to be
>>> sent to the originally-requested resource.
>>> This works great to allow users to pick-up workflows where they 
>>> left-off in the case of session timeout: once authenticated, the
>>> user is sent back to the page they were trying to get to
>>> originally, including a potential re-POST of form data, for
>>> example.
>>> With the CSRF prevention filter in-place, this then causes an
>>> error (well, CSRF policy violation == forbidden response) because
>>> the nonce originally added to the request's query string no
>>> longer matches a valid nonce on the server.
>>> This can be considered both good and bad behavior. Good: if
>>> handed a forged nonce from an attacker, the nonce will not be
>>> valid if the user is asked to login. Session-fixation attacks
>>> could get an attacker around this. Bad: it completely and totally
>>> breaks workflow-resumption.
>>> I'm looking for a way around this because I *really* like the
>>> fact that you can resume a workflow after re-authenticating.
>>> (I happen to be using a 3rd-party authentication and
>>> authorization library implemented as a Filter and I'm having some
>>> issues with getting that working as well, but the problem exists
>>> with the stock Tomcat authenticators.)
>>> Is there a safe way to implement workflow-resumption in the
>>> presence of the CSRF prevention filter? Or even under *any* CSRF
>>> scheme?
>> Use an Origin based protection?
> So something like CORS? I haven't dived into CORS, yet. Is it fair to
> say that CSRF might be a simpler and less powerful standard while CORS
> is a replacement for it? Or do they serve different use-cases?

Different use cases. Origin based CSRF protection is considered less
effective than token based (I'm only going on what I read - I haven't
dug into the whys) but it should be sufficient for the scenario you


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message