Security issue: Redirect-Secret can be set by anyone
WApplication::encodeUntrustedUrl relies on a secret in
redirectSecret_). This is normally randomly generated.
However, a fix for issue #4207 introduced a regression here. We will overwrite
redirectSecret_ with whatever is found in the
Redirect-Secret header, allowing anyone to reassign this variable.
There's also a concurrency issue: many different sessions may concurrently write to
redirectSecret_. In fact, I stumbled upon this when running a Wt build with
-fsanitize=thread (when looking into issue #11101).
To address this:
- Make assignment to
- Only look at the header if we're behind a (trusted) reverse proxy
- Discard any such header before passing it on to the downstream session process
- Rename the header to something like
X-Wt-Redirect-Secretto indicate that it is non-standard
Updated by Roel Standaert about 1 year ago
The vulnerabilities are:
- potential crashes (DoS) by repeatedly changing the
Redirect-Secrettoken (concurrent modifications leading to segmentation faults, and interfering with external links)
- by setting
Redirect-Secretto a token that the attacker knows, an open redirect URL can be created: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
- Side note: the hash is created with MD5 with a secret of 32 alphanumeric characters (with capital letters, 62 possibilities), even though it is only MD5, brute forcing it doesn't seem very feasible