Grouper Users - Open Discussion List

[Carl Waldbieser <>]

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