Login Return-Path Automation: The Redirect Parameter an Attacker Gets to Write

An open redirect is dangerous precisely because the first, most important half of a phishing attempt — getting someone to click a link pointing at a domain they genuinely trust — is already true before the vulnerability is even involved. The link IS the real login page, on the real domain, and clicking it produces a real, correct login screen; a careful person checking the address bar before typing a password sees exactly what they expect to see. The vulnerability activates only at the very end, after a successful, entirely genuine authentication, when the flow honors a redirect target it never actually validated — sending someone who has just done everything right, checked the domain and typed their real password correctly, to a destination an attacker chose, not the module's own default.

Reading a `return` parameter and passing it directly to a redirect call is the most direct, simplest way to implement "send the person back to where they were trying to go" — and for the overwhelming majority of real, ordinary traffic, where that parameter genuinely does contain a normal internal path generated by the application's own linking, it produces exactly the correct, intended behavior with no problem ever surfacing. The gap exists specifically because nothing about ordinary use ever supplies anything OTHER than a normal internal path in that parameter — an attacker crafting the link is the only party with any reason to supply something else, which means the vulnerable branch of the code goes essentially untested by real usage until someone deliberately tries the bypass shapes a redirect-handling audit is specifically built to check for.

A dedicated internal security audit of Centriu Helix (the same 2026-06-02 audit that also closed the error-log cross-tenant finding described on this pillar's companion page) specifically examined how the login flow's own `return` parameter was used, and found it passed unvalidated from the URL directly into the browser's redirect call at BOTH of the login flow's two call sites: the branch that redirects an already-authenticated person away from the login screen, and the branch that redirects a person immediately after a fresh, successful sign-in.

The fix is a small, dedicated, independently-named and independently-tested function specifically built to answer one question: is this a genuine internal relative path, safe to redirect to? It accepts the incoming value only if it is a non-empty string starting with a single forward slash, and explicitly rejects two further bypass shapes that a naive "starts with `/`" check alone would miss entirely: a value starting with `//` (a protocol-relative address, which browsers resolve against whatever protocol the current page happens to be using, silently taking the redirect off the current domain) and a value starting with `/\` (a backslash-based variant of the identical bypass, since browsers commonly normalize a leading backslash to a forward slash before parsing a URL). Anything failing any of these checks falls back to the module's own explicit default landing route, rather than being redirected anywhere derived from the untrusted input at all. Both of the login flow's own call sites — the already-authenticated branch and the fresh-sign-in branch — now route through this identical, shared validation function, closing the gap uniformly rather than patching one call site while leaving the other exploitable.

Before the fix, a link to Helix's own real login page carrying a crafted `return` parameter pointing off-domain would show the genuine login screen, accept a real, correct login, and then redirect that now-authenticated browser to wherever the parameter said — off Helix's own domain entirely, with nothing in the login experience itself indicating anything was wrong. After the fix, the identical crafted link still shows the genuine login screen and still accepts a real login, but the redirect that follows lands only on a genuine internal Helix path — the module's own default screen, if the supplied return value fails validation for any reason.

Centriu Helix's login flow now validates its own return-redirect parameter through a single, shared, independently-tested function at both of its call sites, closing a textbook open-redirect (CWE-601) gap where a crafted link could send a person through a completely genuine login on Helix's own real domain and still end by redirecting their authenticated browser somewhere an attacker chose.

This automation covers specifically Centriu Helix's own login-flow return-path redirect. It is a genuinely different mechanism from this pillar's separate wave 72 page, which addresses an unrelated open-redirect-shaped finding in a different system's development-mode code-return path — not a login redirect at all; a reader looking for that specific finding should see that page directly.

Passing a `return` parameter straight to a redirect call is the simplest possible implementation, and it is correct for every case where the parameter genuinely contains what it is meant to — a normal internal path. The gap is that a URL parameter is, definitionally, something anyone constructing a link fully controls, and "looks like a path" is not the same guarantee as "is definitely an internal path," since both a protocol-relative address and a backslash-prefixed one can look path-like on a quick glance while still redirecting off-domain. Validating against an explicit, narrow allow-shape — accept only a genuine single-leading-slash internal path, reject everything else including the specific known bypass variants — is the only version of the two that closes the gap rather than merely making it slightly less obvious.