websocket POC demo - not production ready.

[devinleighsmith]

NOT a pull request, just sharing a POC.

This is not production ready, as it doesn't have a backplane or proper controls on connections or message size/rates.

Requires these env vars to run:

export CORS_DOMAIN='https://localhost:8080;http://localhost:8080'
export VITE_WS_PROXY_INSECURE=true
export VITE_WS_PROXY_ORIGIN=https://localhost:8080

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot

See analysis details on SonarQube Cloud

In general, to fix log forging when logging user input, ensure the values are normalized or encoded before being passed to the logger. For plain-text logs, the minimal safe step is to remove or replace newline and carriage-return characters (and optionally other control characters) so that a malicious value cannot break log structure or inject fake entries.

Here, we should avoid changing functionality, so we will keep the same logging messages and behavior but sanitize origin before it is first used. Because origin is also used in the later warning (origin mismatch), the safest place is immediately after it is read from the header: create a sanitized version that strips \r and \n, and use that sanitized value in all logging calls, while keeping the original header value for any non-logging logic (if needed). In this snippet, origin is only used for comparisons and logging; stripping newlines will not affect equality checks for valid origins, because valid origins should not contain such characters.

Concretely, in api/Hubs/NotificationsHub.cs:

• After line 23 where origin is read, introduce a new variable sanitizedOrigin that removes newline characters from origin.
• Use sanitizedOrigin instead of origin in the two logging calls that include the origin (lines 25–28 and 50–52).
• No new external dependencies are required; string.Replace and the null-conditional operator are sufficient.

In general, to fix log-forging issues, any user-controlled value should be normalized or encoded before being written to logs. For plain-text logs, this typically means removing or replacing newline characters (\r, \n) and possibly other non-printable control characters so an attacker cannot break the log format or inject extra entries. For logs destined to HTML, HTML-encoding is recommended.

In this specific code, the problematic value is origin read from Request.Headers["Origin"]. The best minimal fix is to sanitize this value once, immediately after reading it, and then use the sanitized value for all logging calls. That keeps observable behavior the same for normal Origin values while stripping potentially dangerous characters (such as newlines) that could be used for log forging. A simple approach, consistent with the recommendation, is to replace any \r and \n with empty strings (or another benign character). We should not alter other logic (such as the origin comparison) unless necessary; to keep functionality unchanged, we can continue to use the original origin for the origin-check logic and use a separate sanitized variable for logging.

Concretely in api/Hubs/NotificationsHub.cs:

• After obtaining origin at line 23, introduce a new variable, e.g., sanitizedOrigin, which is origin with \r and \n removed.
• Update all logging calls that currently pass origin as a parameter (lines 25–28 and 50–52) to pass sanitizedOrigin instead.
• No new external dependencies are needed; this can be done using string.Replace, which is part of the base class library.

This keeps the origin-matching logic identical (still using the original header value) while ensuring logged values cannot contain raw newlines.