tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baron Fujimoto <ba...@hawaii.edu>
Subject Re: CSRF errors after upgrade of tomcat 8
Date Sat, 12 Dec 2015 03:02:43 GMT
On Sat, Dec 12, 2015 at 12:16:01AM +0000, Mark Thomas wrote:
>On 12/12/2015 00:01, Baron Fujimoto wrote:
>> 
>> 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
>>> related?
>>>
>>>> However, Grouper already incorporates CSRF protection using OWASP CSRFGuard
>>>> <https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project>.
>>>>
>>>> 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>, ip:xxx.xxx.xxx.xxx, 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
>> toes.
>> 
>>>> 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
>>>> <https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter_for_REST_APIs>.
>>>
>>> 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
>> me.
>> 
>>>> 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?
>
>The first thing to do is to identify the Tomcat version that introduced
>the problem. That makes reviewing the changelog easier.

I've confirmed that the problem begins with 8.0.29.
>
>If you can find out how the CSRF protection is adding the token then
>that will also help since it gives an idea of what to look for in the
>changelog.

I believe it's done using the OWASP CSRFGuard Project, and I have the
property files generated by the Grouper devs that define its
configuration. I'll query the Grouper folks to confirm and see if they
can provide a relevant and succinct explanation about this in particular.

-baron
-- 
Baron Fujimoto <baron@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message