4 ms·
Why is it the plugin job to mitigate IP Spoofing via X-Forwarded-For Header? Isn’t it the first gateway job? Just like I wouldn’t blame a container server for c
by yonixwm 3y ago
Why is it the plugin job to mitigate IP Spoofing via X-Forwarded-For Header? Isn’t it the first gateway job? Just like I wouldn’t blame a container server for cdn not making sure X-Forwarded-For is not passed from the client…
Meaning how will the plugin know how levels deep is it in the infrastructure… and if you really care about warning devs then it should be a caddy level security bug, not this plugin specifically.
So all those spoofing items is really out of scope for this plugin…
- francislavoie 3y agoCaddy itself has built-in support for correctly & safely parsing XFF via the trusted_proxies global option https://caddyserver.com/docs/caddyfile/options#trusted-proxies https://caddyserver.com/docs/caddyfile/options#trusted-proxi... The plugin should use the parsed client IP produced by this, but the plugin was written before trusted_proxies existed in Caddy. (Not excusing the mistake, but there's an "easy" solution if someone wants to resolve it.)
- yonixwm 3y agoAgain why mention the plugin? Just use the main caddy option… plugins are ment to expand caddy not replace existing directives unless i am missing something and the plugin overrides default behavior then of course it’s to blame
- buro9 3y agoI think a security plugin author should have the awareness that X-Forwarded-For is just a string of untrusted user input. That definitely is the job of a security plugin author who uses the value. Whether it's lesson number one or number two... Don't trust your inputs has got to be near the top of things you learn when doing anything with security. Edit: now I've read the article... Shocked. The vast majority of this is trusting untrusted user input.