Grouper Users - Open Discussion List

[Baron Fujimoto <>]

Sorry for not getting back on this. Unfortunately I don't have an inkling
on what the owasp config file would need.

Apparently though, in the latest Tomcat release 8.0.32, they've changed
the default for mapperContextRootRedirectEnabled to true, so that's no
longer explicitly required in context.xml. But it doesn't hurt to leave
it in there.
<http://tomcat.apache.org/tomcat-8.0-doc/changelog.html#Tomcat_8.0.32_(markt)>

mapperDirectoryRedirectEnabled="true" seems to still be required though.

-baron

On Thu, Dec 17, 2015 at 01:21:08PM +0000, Chris Hyzer wrote:
>Sorry if this is a dumb question... what exactly would the owasp config file 
>have to do compensate for it?  Im interested in that option, since the 
>context xml sounds like a pain
>
>Thanks so much for staying with this one and figuring it out!
>
>Chris
>
>-----Original Message-----
>From: 
>
> 
>[mailto:]
> On Behalf Of Baron Fujimoto
>Sent: Wednesday, December 16, 2015 6:57 PM
>To: Grouper Users
>Subject: Re: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error
>
>The tomcat devs have also confirmed that this will be the default behavior
>for all tomcat releases going forward. Unless there's a way to compensate
>for this via the Owasp.CsrfGuard.properties config file, I suppose it
>should be documented in the Grouper wiki for folks deploying with tomcat.
>
>-baron
>
>On Wed, Dec 16, 2015 at 02:11:38PM +0000, Chris Hyzer wrote:
>>It is really unfortunate that that happened.  Thanks so much for tracking 
>>it down though.
>>
>>-----Original Message-----
>>From: 
>>
>> 
>>[mailto:]
>> On Behalf Of Baron Fujimoto
>>Sent: Tuesday, December 15, 2015 9:53 PM
>>To: Grouper Users
>>Subject: Re: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error
>>
>>I'm not sure if this is a long term solution, but we at least have a
>>workaround now.
>>
>>The Tomcat devs hypothesized that the behavior resulted from the following
>>change for Tomcat 8.0.29:
>>
>>"Move the functionality that provides redirects for context roots and
>>directories where a trailing / is added from the Mapper to the
>>DefaultServlet. This enables such requests to be processed by any
>>configured Valves and Filters before the redirect is made. This behaviour
>>is configurable via the mapperContextRootRedirectEnabled and
>>mapperDirectoryRedirectEnabled attributes of the Context which may be used
>>to restore the previous behaviour."
>>
>>And a workaround that restores the previous behavior is to add the
>>following attributes to ${CATALINA_BASE}/conf/context.xml:
>>
>>mapperContextRootRedirectEnabled="true"
>>mapperDirectoryRedirectEnabled="true"
>>
>>e.g.:
>>
>><Context mapperContextRootRedirectEnabled="true"
>>         mapperDirectoryRedirectEnabled="true">
>>    [...]
>></Context>
>>
>>
>>On Fri, Dec 11, 2015 at 04:57:30PM -1000, Baron Fujimoto wrote:
>>>I sort of got taken to task on tomcat-users for assuming the problem
>>>was with their REST CSRF protection filter (and that it was enabled by
>>>default). I've been asked though how the [OWASP] CSRF protection
>>>is adding the token in order to help guide a search through their
>>>changelog. Can any one fill in the details or provide a reference to
>>>the information they seek? Else, all I really have to offer is the
>>>OWASP CSRFGuarf Project page at
>>>
>>><https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project>
>>>
>>>and our grouper-ui/conf/Owasp.CsrfGuard.*properties files (I don't
>>>think there's any sensitive info in there).
>>>
>>>If anyone is curious, this thread in the tomcat-users mailing list
>>>can be followed at
>>>
>>><http://tomcat.10.x6.nabble.com/CSRF-errors-after-upgrade-of-tomcat-8-td5043864.html>
>>>
>>>-baron
>>>
>>>On Fri, Dec 11, 2015 at 10:28:13AM -1000, Baron Fujimoto wrote:
>>>>Apparently it's on by default, since I didn't do anything to explicitly
>>>>enable it. Unfortunately, I don't see anything in the documentation on how
>>>>to disable it. I'll query the tomcat-users mailing list.
>>>>
>>>>-baron
>>>>
>>>>On Fri, Dec 11, 2015 at 03:43:09PM +0000, Chris Hyzer wrote:
>>>>>Is it on by default?  Can you disable it?  If Grouper has CSRF 
>>>>>protection, then I think you don't need anything from the container...  
>>>>>its not as simple as just turning it on, it takes a lot of carefully 
>>>>>configuration about which URLs need protection etc.
>>>>>
>>>>>Thanks,
>>>>>Chris
>>>>>
>>>>>-----Original Message-----
>>>>>From: 
>>>>>
>>>>> 
>>>>>[mailto:]
>>>>> On Behalf Of Baron Fujimoto
>>>>>Sent: Thursday, December 10, 2015 9:42 PM
>>>>>To: Grouper Users
>>>>>Subject: Re: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error
>>>>>
>>>>>Unearthed this in the Tomcat Changelogs for 8.0.29, which seems like a
>>>>>candidate:
>>>>>
>>>>>"Add a new RestCsrfPreventionFilter that provides basic CSRF protection
>>>>>for REST APIs."
>>>>>
>>>>>Now trying to make sense of this Tomcat documentation:
>>>>>
>>>>><https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter_for_REST_APIs>
>>>>>
>>>>>I don't yet know if the problem is the result of something I need to do
>>>>>with Tomcat's new RestCsrfPreventionFilter, or some interaction between
>>>>>it and Grouper's existing owasp.csrfguard.* stuff (or something else
>>>>>altogether).
>>>>>
>>>>>Presumably there should be an appropriate <Filter> element that goes in
>>>>>the UI's web.xml. Assuming I can sort out how to correctly update 
>>>>>web.xml,
>>>>>what's the best way to have it incorporated as part of the build process?
>>>>>Or would you need to update it after the build? The current web.xml
>>>>>advises, "CHANGE YOUR FILE specified by the build.properties value
>>>>>[additional.web.xml]. The contents of that file are merged into
>>>>>${grouper-ui}/webapp/WEB-INF/web.core.xml" However, when I specify the
>>>>>following in the grouper-ui's build.properties:
>>>>>additional.web.xml=${basedir}/path/to/additional-web.xml I don't see the
>>>>>contents of additional-web.xml incorporated anywhere in the resulting
>>>>>web.xml after the build.
>>>>>
>>>>>Aloha,
>>>>>-baron
>>>>>
>>>>>On Thu, Dec 10, 2015 at 02:31:00PM -1000, Baron Fujimoto wrote:
>>>>>>Thanks for the pointers. Doing a little more due diligence, I realized
>>>>>>that the Grouper versions weren't the only difference in the 
>>>>>>environments.
>>>>>>The 2.2.1 env was running under Tomcat 8.0.24, and the 2.2.2 env was
>>>>>>running under the latest 8.0.30. I upgraded the 2.2.1 env Tomcat to 
>>>>>>8.0.30
>>>>>>and now see the CSRF errors there as well. Backing out to 8.0.24 
>>>>>>restores
>>>>>>the working behavior, so this seems like a smoking gun. The Tomcat 
>>>>>>configs
>>>>>>should be the same between the two instances, so I'll go review the 
>>>>>>Tomcat
>>>>>>changelogs for any documented clues to account for the difference 
>>>>>>between
>>>>>>these versions.
>>>>>>
>>>>>>Aloha,
>>>>>>-baron
>>>>>>
>>>>>>On Thu, Dec 10, 2015 at 09:24:13AM -0500, Waldbieser, Carl wrote:
>>>>>>>
>>>>>>>Followup: Looking in my notes, the header in question is "OWASP_CSRF". 
>>>>>>> We use Nginx, which strips out headers with underscores by default.  
>>>>>>>the setting "underscores_in_headers on;" in the "nginx.conf" file 
>>>>>>>allows that header.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Carl
>>>>>>>
>>>>>>>----- Original Message -----
>>>>>>>From: "waldbiec" 
>>>>>>><>
>>>>>>>To: "Baron Fujimoto" 
>>>>>>><>
>>>>>>>Cc: "Grouper Users" 
>>>>>>><>
>>>>>>>Sent: Thursday, December 10, 2015 9:18:01 AM
>>>>>>>Subject: Re: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF 
>>>>>>>error
>>>>>>>
>>>>>>>Baron,
>>>>>>>
>>>>>>>Not sure if this helps, but when we first set up Grouper, we ran afoul 
>>>>>>>of the CSRF checks because our proxy was not handling an HTTP header 
>>>>>>>correctly.
>>>>>>>I am not sure how you are using CAS (integrated vs. apache + 
>>>>>>>mod_auth_cas) or what your deployment architecture is like, so I am 
>>>>>>>not sure if that helps.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Carl Waldbieser
>>>>>>>ITS Systems Programmer
>>>>>>>Lafayette College
>>>>>>>
>>>>>>>----- Original Message -----
>>>>>>>From: "Baron Fujimoto" 
>>>>>>><>
>>>>>>>To: "Grouper Users" 
>>>>>>><>
>>>>>>>Sent: Wednesday, December 9, 2015 10:32:26 PM
>>>>>>>Subject: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error
>>>>>>>
>>>>>>>While testing our Grouper 2.2 UI deployment which uses CAS for
>>>>>>>authentication, I encountered the following situation:
>>>>>>>
>>>>>>>- Log out
>>>>>>>
>>>>>>>This puts me back at the usual page at
>>>>>>><https://grouper-future.its.hawaii.edu/grouper/logout.do> with the 
>>>>>>>warning
>>>>>>>text, "The only way to be sure that you have logged out is to close ALL
>>>>>>>browser windows."
>>>>>>>
>>>>>>>If I then attempt to log back in from this screen, it sends me back to 
>>>>>>>the
>>>>>>>CAS login page as expected, but after authenticating with CAS I am
>>>>>>>redirected back to a Grouper error page which says "You have an 
>>>>>>>anonymous
>>>>>>>session since you are not logged in, but this section requires you to 
>>>>>>>be
>>>>>>>logged in. Maybe No username found. Your identity provider might not be
>>>>>>>sending your username to this application. Either you need to use a
>>>>>>>different identity provider, or ask your IT department to send your
>>>>>>>username to this application."
>>>>>>>
>>>>>>>In 2.2.1 if I click on the offered option to "Start over" it sends me 
>>>>>>>back
>>>>>>>to /grouper and all proceeds as expected (presumably reusing my 
>>>>>>>existing
>>>>>>>CAS session).
>>>>>>>
>>>>>>>With 2.2.2 I am redirected to an error page that says, "Maybe your 
>>>>>>>session
>>>>>>>timed out and you need to start again. This should not happen under 
>>>>>>>normal
>>>>>>>operation. CSRF error" and the following gets logged:
>>>>>>>
>>>>>>>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)
>>>>>>>
>>>>>>>No matter what I try from this point, including quitting and restarting
>>>>>>>my browser, using the browser's private browsing features, and even
>>>>>>>incredibly (to me) restarting the UI webapp won't get me past this 
>>>>>>>when I
>>>>>>>try to go back to /grouper.
>>>>>>>
>>>>>>>Any ideas on why it's not matching the 2.2.1 behaviour?
>>>>>>>
>>>>>>>Also, FWIW, whenever one of those error pages is loaded, the following
>>>>>>>string is also logged with no context or additional information,
>>>>>>>"Institute of Higher Education". I've tracked this down to
>>>>>>>
>>>>>>>grouper.ui/conf/grouperText/grouper.text.en.us.base.properties:
>>>>>>>institutionName = Institute of Higher Education
>>>>>>>
>>>>>>>Where I suppose we could customize it in grouper.text.en.us.properties?
>>>>>>>However, logging this string as it does currently doesn't seem to serve
>>>>>>>any useful purpose?
>
>-- 
>Baron Fujimoto 
><>
> :: UH Information Technology Services
>minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-- 
Baron Fujimoto 
<>
 :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum