Grouper Users - Open Discussion List

[Baron Fujimoto <>]

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
>
>-- 
>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