mirror of
https://github.com/koel/koel.git
synced 2026-04-26 17:25:59 +03:00
[GH-ISSUE #2015] ProxyAuthService::validateProxyIp relies on $request->ip() (which may honor X-Forwarded-For) rather than raw socket address #1061
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#1061
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Anduin2017 on GitHub (Jul 11, 2025).
Original GitHub issue: https://github.com/koel/koel/issues/2015
ProxyAuthService::validateProxyIprelies on$request->ip()(which may honorX-Forwarded-For) rather than raw socket address, causing SSO to fail when client IP ≠ proxy IPgithub.com/koel/koel@ccbcea8255/app/Services/ProxyAuthService.php (L37)Description
In ProxyAuthService the call to
$request->ip()is used to validate that the incoming request comes from a trusted proxy. However, Laravel/Symfony’s$request->ip()will, by default, trustX-Forwarded-Forheaders when the client’s IP is in the “trusted proxies” list. This means:X-Forwarded-For) falls within one of the allowed CIDRs inPROXY_AUTH_ALLOW_LIST, the request is accepted—even if the proxy’s own IP is not allowed.This behavior undermines the whole point of restricting proxy authentication to known reverse-proxy addresses, and can both open security holes (clients spoofing headers to match allowed ranges) and break valid SSO when client IPs differ from proxy IPs.
Steps to Reproduce
Configure Koel with Proxy Authentication enabled in
.env:Ensure your reverse proxy (e.g. Caddy/Traefik) is set as a trusted proxy in Laravel’s
TrustProxiesmiddleware so that$request->ip()reflects the client IP fromX-Forwarded-For.From a client IP in
192.168.0.0/16, access Koel through the proxy → SSO succeeds (because$request->ip()= client IP in allow list).From a client IP outside
192.168.0.0/16, access Koel through the same proxy → SSO fails (because$request->ip()= client IP, not proxy’s IP).Expected Behavior
validateProxyIp()should verify the proxy’s own address (i.e. the TCP source IP) againstproxy_auth.allow_list, not the client IP forwarded by headers. That ensures only configured reverse proxies can perform header-based SSO, regardless of end-user address.Actual Behavior
validateProxyIp()callsIpUtils::checkIp($request->ip(), …), and$request->ip()may resolve to the real client’s IP (fromX-Forwarded-For) instead of the proxy’s IP, allowing unauthorized header injection or outright blocking valid SSO sessions.Possible Solutions
$request->ip()with$request->server->get('REMOTE_ADDR')for proxy validation.proxy_auth.use_forwarded_ip(defaultfalse) to toggle whether to trust forwarded IPs.REMOTE_ADDRand the “computed” client IP to help operators debug mis-matches.Environment
@Anduin2017 commented on GitHub (Jul 11, 2025):
Possible fix? (I'm not a PHP expert, not tested):
@phanan commented on GitHub (Jul 13, 2025):
Good point, and thanks for the PR. TBH I'm not a network expert (which is the major reason why this feature is in Beta). I'll take a further look :)
@phanan commented on GitHub (Jul 13, 2025):
Closesd by the PR.