When the user tries to perform a verification on the Cryptshare user interface, the "Next" button does not respond (but the unresponsiveness can also occur at other places). Additionally, the browser console logs lots of errors with the message "Origin does not correspond to request".
- Cryptshare Version 4 and above, although the specific behaviour may differ between 4.0/4.1 and later versions.
This issue is most likely caused by a misconfigured reverse proxy.
Beginning with Cryptshare Version 4, requests to the server are checked for the '"Origin' " header, to prevent CSRF attacks. If the '"Origin' " header is missing, or it differs from the protocol, host (and port, if supplied) of the request "Host" header and/or the requested URL, the server responds with Status Code status code 400 (Bad Requestbad request). These headers are set by the browser and sent to the Cryptshare Server.
If the a reverse proxy performs an SSL termination and the request URL arrives on the Cryptshare server as "HTTP" instead of "HTTPS" as originally intended, the request URL and 'Origin' header do not match.
There are two different approaches to mitigate the issue:
is used, both "Host" and "Origin" headers will most likely contain the hostname, port (if any) and scheme of the reverse proxy. If these headers are not adapted accordingly, the Cryptshare Server will detect a mismatch with the requested URL as described above, because the URL targets the Cryptshare Server, not the reverse proxy.
To make sure that the Cryptshare Server recieves requests with matching URL, "Host" and "Origin" header, both headers need to be adapted/set by the reverse proxy. Depending on the product, this may happen for the "Host" header automatically.
Let's say the hostname of the Cryptshare Server would be "cryptshare-internal", the headers would need to be set as follows:
If the port number of the Cryptshare Server differs from the default, it also has to be specified in both servers. For example:
|Content by Label|