You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Baron Fujimoto <ba...@hawaii.edu> on 2015/12/11 22:10:54 UTC
CSRF errors after upgrade of tomcat 8
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."
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. How do I disable
it? 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>.
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.
--
Baron Fujimoto <ba...@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
Re: CSRF errors after upgrade of tomcat 8
Posted by Mark Thomas <ma...@apache.org>.
On 16/12/2015 02:41, Baron Fujimoto wrote:
> On Tue, Dec 15, 2015 at 09:37:45AM +0200, Violeta Georgieva wrote:
<snip/>
>> mapperContextRootRedirectEnabled and
>> mapperDirectoryRedirectEnabled
>>
>> are attributes of the Context so your context.xml should look like the one
>> below:
>>
>> <Context mapperContextRootRedirectEnabled="true"
>> mapperDirectoryRedirectEnabled="true">
>> <WatchedResource>WEB-INF/web.xml</WatchedResource>
>> <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
>> </Context>
>>
>> Regards,
>> Violeta
>
> That works! Mahalo for correcting the context.xml syntax. This workaround
> will allow us to stay current with the latest Tomcat release. Is this
> expected to be the default behavior going forward?
Yes. This is the default behaviour for all Tomcat releases going forwards.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
Posted by Baron Fujimoto <ba...@hawaii.edu>.
On Tue, Dec 15, 2015 at 09:37:45AM +0200, Violeta Georgieva wrote:
>Hello,
>
>2015-12-15 4:35 GMT+02:00 Baron Fujimoto <ba...@hawaii.edu>:
>>
>> On Mon, Dec 14, 2015 at 09:12:20PM +0000, Mark Thomas wrote:
>> >On 14/12/2015 20:49, Baron Fujimoto wrote:
>> >> 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:
>> >
>> ><snip/>
>> >
>> >>> I've confirmed that the problem begins with 8.0.29.
>> >
>> >Looking through the changelog it is hard to see how any of the changes
>> >not in the Catalina section could trigger this. So, focussing on that
>> >section...
>> >
>> >>>> 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)".
>> >
>> >That doesn't explain how/where the token is generated or what component
>> >validates it server side. I'm guessing a Filter does the validation.
>> >
>> >> Per the properties file, I believe the following are excluded:
>> >>
>> >> org.owasp.csrfguard.unprotected.Default=%servletContext%/
>> >
>> >Hmm. This first one combined with the last entry in the Catalina section
>> >of the 8.0.29 changelog look like a possibility.
>> >
>> >Try each of the following (one at a time, not together) to see if they
>> >fix it:
>>
>> Neither of these, tried independently, appeared to have any effect.
>>
>> >a) Add the following (note the lack of trailing slash) to the properties
>> >file:
>> >
>> >org.owasp.csrfguard.unprotected.Upload=%servletContext%
>>
>> I tried this as described, but since I wasn't sure if you really meant the
>> .Default property I also tried that, just in case (separate tests,
>> performed independently). I tried both by adding the suggested definitions
>> after their original definitions (in case they superceded them) and by
>> replacing the original definitions.
>>
>>
>> >b) Set mapperContextRootRedirectEnabled="true" and
>> >mapperDirectoryRedirectEnabled="true" on the Context in
>> >$CATALINA_BASE/conf/context.xml
>>
>> The resulting $CATALINA_BASE/conf/context.xml was:
>>
>> <Context>
>> <WatchedResource>WEB-INF/web.xml</WatchedResource>
>> <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
>>
>> mapperContextRootRedirectEnabled="true"
>> mapperDirectoryRedirectEnabled="true"
>> </Context>
>
>mapperContextRootRedirectEnabled and
>mapperDirectoryRedirectEnabled
>
>are attributes of the Context so your context.xml should look like the one
>below:
>
><Context mapperContextRootRedirectEnabled="true"
>mapperDirectoryRedirectEnabled="true">
> <WatchedResource>WEB-INF/web.xml</WatchedResource>
> <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
></Context>
>
>Regards,
>Violeta
That works! Mahalo for correcting the context.xml syntax. This workaround
will allow us to stay current with the latest Tomcat release. Is this
expected to be the default behavior going forward?
Aloha,
-baron
>> >>
>> >> [...]
--
Baron Fujimoto <ba...@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
Re: CSRF errors after upgrade of tomcat 8
Posted by Violeta Georgieva <mi...@gmail.com>.
Hello,
2015-12-15 4:35 GMT+02:00 Baron Fujimoto <ba...@hawaii.edu>:
>
> On Mon, Dec 14, 2015 at 09:12:20PM +0000, Mark Thomas wrote:
> >On 14/12/2015 20:49, Baron Fujimoto wrote:
> >> 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:
> >
> ><snip/>
> >
> >>> I've confirmed that the problem begins with 8.0.29.
> >
> >Looking through the changelog it is hard to see how any of the changes
> >not in the Catalina section could trigger this. So, focussing on that
> >section...
> >
> >>>> 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)".
> >
> >That doesn't explain how/where the token is generated or what component
> >validates it server side. I'm guessing a Filter does the validation.
> >
> >> Per the properties file, I believe the following are excluded:
> >>
> >> org.owasp.csrfguard.unprotected.Default=%servletContext%/
> >
> >Hmm. This first one combined with the last entry in the Catalina section
> >of the 8.0.29 changelog look like a possibility.
> >
> >Try each of the following (one at a time, not together) to see if they
> >fix it:
>
> Neither of these, tried independently, appeared to have any effect.
>
> >a) Add the following (note the lack of trailing slash) to the properties
> >file:
> >
> >org.owasp.csrfguard.unprotected.Upload=%servletContext%
>
> I tried this as described, but since I wasn't sure if you really meant the
> .Default property I also tried that, just in case (separate tests,
> performed independently). I tried both by adding the suggested definitions
> after their original definitions (in case they superceded them) and by
> replacing the original definitions.
>
>
> >b) Set mapperContextRootRedirectEnabled="true" and
> >mapperDirectoryRedirectEnabled="true" on the Context in
> >$CATALINA_BASE/conf/context.xml
>
> The resulting $CATALINA_BASE/conf/context.xml was:
>
> <Context>
> <WatchedResource>WEB-INF/web.xml</WatchedResource>
> <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
>
> mapperContextRootRedirectEnabled="true"
> mapperDirectoryRedirectEnabled="true"
> </Context>
mapperContextRootRedirectEnabled and
mapperDirectoryRedirectEnabled
are attributes of the Context so your context.xml should look like the one
below:
<Context mapperContextRootRedirectEnabled="true"
mapperDirectoryRedirectEnabled="true">
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
</Context>
Regards,
Violeta
> Aloha,
> -baron
>
> >> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: CSRF errors after upgrade of tomcat 8
Posted by Baron Fujimoto <ba...@hawaii.edu>.
On Mon, Dec 14, 2015 at 09:12:20PM +0000, Mark Thomas wrote:
>On 14/12/2015 20:49, Baron Fujimoto wrote:
>> 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:
>
><snip/>
>
>>> I've confirmed that the problem begins with 8.0.29.
>
>Looking through the changelog it is hard to see how any of the changes
>not in the Catalina section could trigger this. So, focussing on that
>section...
>
>>>> 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)".
>
>That doesn't explain how/where the token is generated or what component
>validates it server side. I'm guessing a Filter does the validation.
>
>> Per the properties file, I believe the following are excluded:
>>
>> org.owasp.csrfguard.unprotected.Default=%servletContext%/
>
>Hmm. This first one combined with the last entry in the Catalina section
>of the 8.0.29 changelog look like a possibility.
>
>Try each of the following (one at a time, not together) to see if they
>fix it:
Neither of these, tried independently, appeared to have any effect.
>a) Add the following (note the lack of trailing slash) to the properties
>file:
>
>org.owasp.csrfguard.unprotected.Upload=%servletContext%
I tried this as described, but since I wasn't sure if you really meant the
.Default property I also tried that, just in case (separate tests,
performed independently). I tried both by adding the suggested definitions
after their original definitions (in case they superceded them) and by
replacing the original definitions.
>b) Set mapperContextRootRedirectEnabled="true" and
>mapperDirectoryRedirectEnabled="true" on the Context in
>$CATALINA_BASE/conf/context.xml
The resulting $CATALINA_BASE/conf/context.xml was:
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
mapperContextRootRedirectEnabled="true"
mapperDirectoryRedirectEnabled="true"
</Context>
Aloha,
-baron
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2015 20:49, Baron Fujimoto wrote:
> 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:
<snip/>
>> I've confirmed that the problem begins with 8.0.29.
Looking through the changelog it is hard to see how any of the changes
not in the Catalina section could trigger this. So, focussing on that
section...
>>> 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)".
That doesn't explain how/where the token is generated or what component
validates it server side. I'm guessing a Filter does the validation.
> Per the properties file, I believe the following are excluded:
>
> org.owasp.csrfguard.unprotected.Default=%servletContext%/
Hmm. This first one combined with the last entry in the Catalina section
of the 8.0.29 changelog look like a possibility.
Try each of the following (one at a time, not together) to see if they
fix it:
a) Add the following (note the lack of trailing slash) to the properties
file:
org.owasp.csrfguard.unprotected.Upload=%servletContext%
b) Set mapperContextRootRedirectEnabled="true" and
mapperDirectoryRedirectEnabled="true" on the Context in
$CATALINA_BASE/conf/context.xml
Mark
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
Posted by Baron Fujimoto <ba...@hawaii.edu>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
Posted by Baron Fujimoto <ba...@hawaii.edu>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
Posted by Baron Fujimoto <ba...@hawaii.edu>.
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?
Aloha,
-baron
--
Baron Fujimoto <ba...@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
Re: CSRF errors after upgrade of tomcat 8
Posted by Mark Thomas <ma...@apache.org>.
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.
> 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.
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org