investigate HTTP Response Header injection

Problem

The application reflects the value of any HTTP headers into the response headers. This may allow an attacker to insert arbitrary code into the response, including additional HTTP head- ers and potentially body content. An attacker can leverage HTTP response header injection to perform cross-site scripting, cross-user defacement, cache poisoning attacks and more. However, due to cross-origin setting of HTTP headers being blocked by the CORS policy, the severity of this finding is set to Medium.

Steps to verify

Perform a GET request with with a valid JWT and a set-cookie header and observe the set-cookie header in HTTP response, e.g:

GET /users?query=%28id%3D%3D%22f5f46a28-d34f-4c8d-9e7f-d88206141d12%22%20or%20id% 3D%3D%22a058f28f-80ac-4994-add6-e4d02fc238fe%22%20or%20id%3D%3D%22e19ae972-63 41-4451-9ca1-1f4aabfc986e%22%29
query urldecoded: (id=="f5f46a28-d34f-4c8d-9e7f-d88206141d12" or id=="a058f28f-80ac-4994-add6-e4d02fc238fe" or id=="e19ae972-6341-4451-9ca1-1f4aabfc986e")

Acceptance criteria
This problem has been addressed in RMB-478 (commit 3ae1e2c, v27.1.2) and OKAPI () but the problem has been reported again during the NCC audit.

Ensure that:

• that header reflection via GET no longer works
• verify that all FOLIO backend modules have been upgraded to RMB with the problem solved (platform-complete) and create tickets in Jira for the modules with issues
• verify that non-RMB FOLIO backend modules in platform-complete do not allow for header injection – test w X-Okapi header (token, tenant) and a standard header like Set-Cookie
• review the fix implemented for RMB and Okapi, propose improvements (if any)

List of Q1 modules: https://docs.google.com/spreadsheets/d/1NvvCq1wTfDeCnd7zHDIzLI7RBfuSr_Ty0tbzYzgEaI8/edit#gid=0