Emond Papegaaij created WICKET-7198:
---------------------------------------
Summary: WebSocket base URL retains the client-supplied authority
Key: WICKET-7198
URL: https://issues.apache.org/jira/browse/WICKET-7198
Project: Wicket
Issue Type: Bug
Components: wicket-native-websocket
Reporter: Emond Papegaaij
Assignee: Martin Tzvetanov Grigorov
{\{AbstractWebSocketProcessor}} reads the \{{wicket-ajax-baseurl}} parameter
from the WebSocket handshake and parses it with \{{Url.parse(CharSequence)}},
which treats the value as a possibly-full URL and therefore retains its scheme,
host and port. The result is installed as the \{{UrlRenderer}} base URL for
every request cycle that connection produces.
The HTTP and Ajax paths do not work this way: \{{ServletWebRequest}} overwrites
scheme, host and port with the container-reported values before the base URL is
used. The WebSocket path has no equivalent step.
As a result, any URL rendered in full form during a request cycle on that
connection takes its authority from a value supplied by the client rather than
from the container.
A legitimate client never populates the authority at all — the value a browser
sends is a single \{{.}} — so sanitising it cannot break any existing client.
{\{SECURITY.md}} states the invariant without qualification: the host, port and
protocol of that URL are always overwritten with the container-reported values,
and the client can influence the path Wicket renders relative to, never the
authority. That currently holds for the Ajax path only.
h3. Suggested fix
Apply the same sanitisation on the WebSocket path that the Ajax path already
applies, so that the authority always comes from the container.
Two things to watch out for:
# The copied upgrade request reports its scheme as \{{ws}}/\{{wss}} rather than
\{{http}}/\{{https}}. Copying it over verbatim would put \{{ws://}} into
rendered links.
# The Ajax path additionally marks the base URL as context-relative. That is a
separate behavioural decision and is not required in order to fix the authority.
h3. Notes
Framework code does not currently render full URLs inside a WebSocket request
cycle, so this surfaces only where the application renders an absolute or
context-absolute URL itself. Either way the base URL should not be carrying a
client-supplied authority.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
