Hacker News Reader

Comment by fffrantz | Hacker News Reader

Honestly, reverse proxying anything with Caddy has been so easy that I can’t use anything else anymore. Docker containers are utterly easy to proxy, the defaults (e.g. the php_fastcgi directive) are sane and mostly work out of the box, the documentation is great, and everything seems so well thought out that one has to wonder why we put up so long with the convolutions of Apache and Nginx.

View on HN

I take issue with the Caddy 2 admin API. It is easy to disable, but it's enabled by default(!!!) and requires no authentication!

Besides that Caddy is indeed amazing and very well thought out!

It's only accessible on the loopback interface.

Indeed, but still, one SSRF vulnerability in anything on the host and the attacker can reconfigure Caddy to serve up any other resource on any of the networks the host can access, or deny access to any resources served by Caddy.

It's an unnecessary security risk is all I'm saying, and I personally would have preferred it was authenticated or off by default.

I really love Caddy, you've built an amazing piece of software, I just disagree with your design decision on this one little thing. It's good that you put that notice in the docs at least!

Glad you love Caddy.

If the host is popped, I'm not sure what Caddy can do to save you. Even authentication has to be stored on the machine... that was popped.

SSRF and RCE are different things. Being able to throw requests to localhost and accessing the host filesystem don't necessarily have to be the same vulnerabilities, but I'll concede that SSRF vulns are uncommon.

I'm just worried that Caddy will be the source of "security misconfiguration" (1) findings in penetration test reports. It's my opinion that we as software engineers should strive not to leave our software insecure by default, is what I'm saying, and that's how I see Caddy 2's admin API.

1: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

Ahhh, unauthenticated services on the loopback. For when you want to be penetrated from behind via javascript drive-by.

Yes, including your server, because you're probably forwarding that port to your workstation via ssh.

Can you demonstrate an exploit in Caddy itself (i.e. isn't actually exploiting something else, or configuring yourself into a hole first -- we can't do much about external factors)? If it's valid we'll see about a patch.

Reply on news.ycombinator.com