LTI login forwards attacker-controlled target_link_uri as OIDC redirect_uri without validating it against the registered tool URLs

Area: mobieusLearn (audit p8) · Surface: GET|POST /lti/login · Dimension: security · Severity: minor

LTI 1.3 §5.1.1.1 requires the tool to ensure target_link_uri matches a registered redirect URI before using it. Here the platform's auth_login_url (trusted) is the redirect target, so the immediate browser navigation stays on the LMS; the risk is that the redirect_uri we hand the LMS is attacker-chosen, which (a) can confuse/mis-route the eventual id_token form_post depending on the LMS's own redirect_uri validation, and (b) is a deviation from spec that some LMSs will reject and others will honor. Practical exploitability depends on the LMS, so this is minor rather than a confirmed open redirect, but it is an unvalidated-redirect-parameter pattern.

Evidence

platform/src/Controllers/Learn/LearnLtiController.php:58 `$targetLinkUri = (string)($params['target_link_uri'] ?? '');` then line 103 inside http_build_query: `'redirect_uri' => $targetLinkUri,` — the value is taken straight from untrusted GET/POST and placed into the OIDC auth request as redirect_uri, with the only validation being the non-empty check at line 62. There is no allowlist tying target_link_uri to the tenant's own /lti/launch URL or the registered platform's expected tool URLs.

Suggested fix. Validate target_link_uri before building the auth request: require it to be an https URL whose host equals the tenant's canonical host (the same tenantHost()/MOBIEUS_TENANT_HOST pinning used elsewhere in this controller) and whose path is an allowed tool launch path (e.g. /lti/launch). Reject otherwise via loginError('invalid_target_link_uri', ...).

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.