Implement Double Submit Cookie Sessions to mitigate simple session hijacking methods
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
Currently, if a malicious actor is able to access another user's _gitlab_session cookie that actor is able to gain access to the user's account and impersonate them for the duration of the session timeout. There are several attack methods which might expose the value in this cookie including cross site scripting, malware, compromise of the host, or cookie stealing scripts.
Proposal
The feature being proposed is an OWASP recommended practice called Double Submit Cookie. The idea is that by sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value are equal. If the user's session information is stolen through one of the previously mentioned attacks, the cryptographic secret won't match and the session identifier should be invalidated causing the user should be required to reauthenticate.
Further details
This was initially highlighted as a concern to an ultimate Public Sector Customer who has an increased threat model that they need to account for via: https://gitlab-federal-support.zendesk.com/agent/tickets/1537 (internal link, US Public Sector access required)