tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baron Fujimoto <>
Subject Re: CSRF errors after upgrade of tomcat 8
Date Sat, 12 Dec 2015 00:01:08 GMT

On Fri, Dec 11, 2015 at 09:25:12PM +0000, Mark Thomas wrote:
>On 11/12/2015 21:10, Baron Fujimoto wrote:
>> After upgrading Tomcat from 8.0.24 to 8.0.30, one of our applications
>> (Internet2's Grouper) "broke" with CSRF errors. Research turned up the
>> following in the Tomcat8 Changelog:
>> "Add a new RestCsrfPreventionFilter that provides basic CSRF protection
>> for REST APIs."
>Apart from the fact that that entry includes "CSRF" and it is your CSRF
>protection that is broken, what evidence to you have that the two are
>> However, Grouper already incorporates CSRF protection using OWASP CSRFGuard
>> <>.
>> It appears that the new Tomcat RestCSRF feature interacts with OWASP
>> CSRFGuard poorly. The new Tomcat RestCSRF is apparently enabled by default
>> since I did not to anything to specifically enable it.
>What are you basing this assertion on? Evidence to back up the claim
>that Tomcat's RestCSRF protection is enabled by default is required.

Ok, I'll concede your points. This is what I know:

Upgrading Tomcat from 8.0.24 to 8.0.30 resulted in CSRF related failures.
I made no other changes to the existing Tomcat or application configs.
Therefore I concluded that the new failure mode is the result of some
difference between the Tomcat versions. Reverting back to 8.0.24
eliminates the problem.

The actual error logged is from the OWASP CSRFGuard package.

ERROR CsrfGuardLogger.log(47) -  - potential cross-site request forgery (CSRF) attack thwarted
(user:<anonymous>,, method:GET, uri:/grouper/grouperUi, error:required
token is missing from the request)

So I, naively perhaps, looked for CSRF related changes that may have
accounted for that. It seemed reasonable, to me at least, that two
features purported to serve similar purposes could step on each other's

>> How do I disable it?
>The same way you disable any Servlet Filter.
>> I didn't see any information on how to do this in the documentation at
>> <>.
>The Tomcat docs assume that users of Tomcat are familiar with the
>Servlet specification and therefore don't need to be told the details of
>how to enable/disable Filters, Servlets etc.

I will also concede I have not waded through the 200+ page Servlet
specification doc. I have now looked over the filter section of the
specification, and based on section 6.2.4, "A filter is defined ... in the
deployment descriptor using the <filter> element" I'm inferring that a
filter is not enabled unless so defined. If this is in fact explicitly
stated somewhere, then I have overlooked it. I'll simply note though that
some sort of documentation to that effect would add a lot of clarity for

>> Since the app already provides CSRF protection that is carefully
>> configured it with which URLs need protection, etc., it seems redundant
>> for the container to do it. And actually, since it has now apparently
>> broken the app, I would like to turn it off Tomcat's version.
>Again, where is the evidence that Tomcat RestCSRF filter is responsible
>for the behaviour you are seeing?
>Hint: The root cause is not what you think it is. You need to do a
>little more research.

As I've conceded, I may well have made an unwarranted assumption
about the probable root cause. Let me take a step back then and ask,
given the problems encountered as a result of the upgrade, what
can I do to identify the source of the problem?

Baron Fujimoto <> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

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

View raw message