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 <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
