Wt

WApplication::encodeUntrustedUrl relies on a secret in WebController (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 redirectSecret_ atomic
• 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-Secret to indicate that it is non-standard