On Fri, Dec 11, 2015 at 05:02:43PM -1000, Baron Fujimoto wrote: >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.
The Grouper devs explain, "Javascript sets an HTTP header called OWASP_CSRFTOKEN: on requests (some excluded per properties file)". Per the properties file, I believe the following are excluded: org.owasp.csrfguard.unprotected.Default=%servletContext%/ org.owasp.csrfguard.unprotected.Upload=%servletContext%/upload.html org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet org.owasp.csrfguard.unprotected.Ajax=%servletContext%/ajax.html org.owasp.csrfguard.unprotected.Error=%servletContext%/error.html org.owasp.csrfguard.unprotected.Index=%servletContext%/index.html org.owasp.csrfguard.unprotected.JavaScript=%servletContext%/javascript.html org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp org.owasp.csrfguard.unprotected.Redirect=%servletContext%/redirect.jsp org.owasp.csrfguard.unprotected.Forward=%servletContext%/forward.jsp org.owasp.csrfguard.unprotected.Session=%servletContext%/session.jsp CSRFGuard defines the following actions for a detected attack: org.owasp.csrfguard.action.Log=org.owasp.csrfguard.action.Log org.owasp.csrfguard.action.Log.Message=potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, method:%request_method%, uri:%request_uri%, error:%exception_message%) org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect org.owasp.csrfguard.action.Redirect.Page=%servletContext%/error.html org.owasp.csrfguard.action.Rotate=org.owasp.csrfguard.action.Rotate Other misc CSRFGuard confs: org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN org.owasp.csrfguard.TokenLength=32 org.owasp.csrfguard.PRNG=SHA1PRNG org.owasp.csrfguard.PRNG.Provider=SUN org.owasp.csrfguard.JavascriptServlet.domainStrict = true org.owasp.csrfguard.JavascriptServlet.cacheControl = private, maxage=28800 org.owasp.csrfguard.JavascriptServlet.refererPattern = .* org.owasp.csrfguard.JavascriptServlet.refererMatchDomain = true org.owasp.csrfguard.JavascriptServlet.injectIntoForms = true org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = true Here is an example of a resulting URL/token that results in the error. <https://foo.example.edu/grouper/grouperExternal/public/UiV2Public.index?operation=UiV2Public.postIndex&function=UiV2Public.error&code=csrf&OWASP_CSRFTOKEN=0JO3-QLCE-98Q4-35G2-6ADK-A352-3NNJ-4H5O> Aloha, -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
