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. 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
