Grouper Users - Open Discussion List

[Baron Fujimoto <>]

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