Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

If you are on slack you will get better responses on the incommon-grouper channel

Any chance you can upgrade to the latest 2.5?  This is a non enhancement version that you dont have to worry about changes in upgrades.

We have changed how CSRFguard works in 2.5, maybe you could compare your csrfguard config files with the ones from 2.5 and adjust yours to use the same strategy?  If you need more info please post the error logs about the CSRF error, but maybe it has to do with Grouper previously having an "allow list" of urls, but really it should be a "deny list" so that extraneous URLs can pass through and not be worried about (browsers send requests for resources not in the application)

---

From: <> on behalf of Carl Waldbieser <>
Sent: Thursday, December 2, 2021 1:07 PM
To: grouper-users <>
Subject: [grouper-users] OWASP_CSRF token issue

 

We've been running Grouper 2.2 for a long time and haven't had any major issues with CSRF going wonky until recently.  I suspect it had to do with a recent OS update that updated the Apache httpd service we have in front of Grouper.

Now, a number of users are seeing the "CRSF error".  I'm not entirely sure what's going on, but I see request logs like the following:

[02/Dec/2021:12:52:20 -0500] 192.168.100.94 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "-" "-""GET /grouper/index.jsp HTTP/1.1" 151
[02/Dec/2021:12:52:20 -0500] 192.168.100.94 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "-" "-""GET /grouper/grouperUi HTTP/1.1" -
[02/Dec/2021:12:52:20 -0500] 192.168.100.94 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "-" "-""GET /grouper/grouperExternal/public/UiV2Public.index?operation=UiV2Public.postIndex&function=UiV2Public.error&code=csrf&OWASP_CSRFTOKEN=HBSS-2FWB-BL2S-HAIJ-KAZB-XYDL-SYBG-L3NW HTTP/1.1" 5600
[02/Dec/2021:12:52:21 -0500] 192.168.100.94 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "-" "-""GET /grouper/grouperExternal/public/OwaspJavaScriptServlet HTTP/1.1" 14031
[02/Dec/2021:12:52:21 -0500] 192.168.100.94 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "1" "-""POST /grouper/grouperExternal/public/OwaspJavaScriptServlet HTTP/1.1" 55
[02/Dec/2021:12:52:21 -0500] 192.168.100.94 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "-" "HBSS-2FWB-BL2S-HAIJ-KAZB-XYDL-SYBG-L3NW, HBSS-2FWB-BL2S-HAIJ-KAZB-XYDL-SYBG-L3NW" "POST /grouper/grouperExternal/public/UiV2Public.postIndex?function=UiV2Public.error&code=csrf&OWASP_CSRFTOKEN=HBSS-2FWB-BL2S-HAIJ-KAZB-XYDL-SYBG-L3NW HTTP/1.1" 4559

I am logging the values of the headers FETCH_TOKEN and OWASP_CSRFTOKEN in the 5th and 6th fields.

To me, it looks like the OwaspJavaScriptServlet resource is hit with a GET to obtain the token, and later hit with a POST and the FETCH_TOKEN header set to a 1 to get the token.  Finally, another POST is made to "UiV2Public.postIndex" with the contents of the CSRF token in the OWASP_CSRFTOKEN 2 times(???) separated by a comma.  The latter results in the failure that the end user sees.

I am wondering if it has anything to do with the fact that the headers have underscores, and maybe an update to the Apache httpd server is causing the issue?  The host OS is pretty old, and I tried reverting the changes, but that unfortunately failed so I don't have a really easy way to test my theory.  Is there any way to force the header names to have hyphens or another name entirely?

Thanks,

Carl Waldbieser

ITS

Lafayette College