3 ms·

Alternatively don't serve your site over HTTP at all. Just redirect to HTTPS. Edit, I just checked the Caddyfile for one of my sites. There is no config for re

Alternatively don't serve your site over HTTP at all. Just redirect to HTTPS. Edit, I just checked the Caddyfile for one of my sites. There is no config for redirecting HTTP to HTTPS is does it automatically. So this is entirely unnecessary.

rekoil 3y ago
No what I'm talking about here is the unauthenticated JSON-based configuration API that hosts itself on port 2019 on localhost of the machine that runs Caddy. This is unrelated to sites hosted using HTTP. I was clumsily using the term "HTTP" to refer to the fact that this configuration mechanism is based on HTTP-communication.
- executesorder66 3y ago
  So if I understand this correctly, anyone can bring down a site with a Caddy server by just running : curl -X POST "https://example.com:2019/stop https://example.com:2019/stop" ? [0] Seems counter to their objective of having secure defaults. [0] https://caddyserver.com/docs/api#post-stop https://caddyserver.com/docs/api#post-stop
  - jorams 3y ago
    No, it is only bound to localhost.
  - gkbrk 3y ago
    No, by default it listens on localhost. So only processes running on the same machine can connect to that port.
    - executesorder66 3y ago
      Okay that makes sense. So why would you bother disabling this thing? I'd imagine if someone already has local access to the server, it's already too late.
      - mcint 3y ago
        Most people would expect that `sudo` and `curl localhost:2019` are very different permissions, that is, curl with post payload `-d '{"admin":{"remote":{"listen":"0.0.0.0:2019"}}}'`, and you'd only have to convince an existing process to make the request.
      - rekoil 3y ago
        SSRF in an application is a serious issue to have on its own, that's true, but in combination with a Caddy admin endpoint it can be used to give an attacker full access to your local network. You could have a blind SSRF vulnerability in an application and while that's not great, it is difficult for an attacker to exploit successfully. If the attacker knows or guesses you're hosting Caddy on the same machine, they know you most likely have an admin interface on localhost:2019 that they can use to make further local network requests and also makes it possible for them to access the results of their local network requests they were making through the blind SSRF vulnerability hypothesised above. Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it, see: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
        francislavoie 3y ago
        > Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it Actually, most everyone wants zero-downtime config reloads. The API is necessary to perform config reloads. As others have said, you may use a unix socket instead for the admin endpoint. And see https://news.ycombinator.com/item?id=37482096 https://news.ycombinator.com/item?id=37482096, we plan to make that the default in certain distributions.
        yencabulator 3y ago
        > The API is necessary to perform config reloads. Of course it isn't. It could reload the config from the same path it loaded the config from in the first place. Like practically all other software has done for decades.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]

rekoil 3y ago

No what I'm talking about here is the unauthenticated JSON-based configuration API that hosts itself on port 2019 on localhost of the machine that runs Caddy. This is unrelated to sites hosted using HTTP. I was clumsily using the term "HTTP" to refer to the fact that this configuration mechanism is based on HTTP-communication.

executesorder66 3y ago
So if I understand this correctly, anyone can bring down a site with a Caddy server by just running : curl -X POST "https://example.com:2019/stop https://example.com:2019/stop" ? [0] Seems counter to their objective of having secure defaults. [0] https://caddyserver.com/docs/api#post-stop https://caddyserver.com/docs/api#post-stop
- jorams 3y ago
  No, it is only bound to localhost.
- gkbrk 3y ago
  No, by default it listens on localhost. So only processes running on the same machine can connect to that port.
  - executesorder66 3y ago
    Okay that makes sense. So why would you bother disabling this thing? I'd imagine if someone already has local access to the server, it's already too late.
    - mcint 3y ago
      Most people would expect that `sudo` and `curl localhost:2019` are very different permissions, that is, curl with post payload `-d '{"admin":{"remote":{"listen":"0.0.0.0:2019"}}}'`, and you'd only have to convince an existing process to make the request.
    - rekoil 3y ago
      SSRF in an application is a serious issue to have on its own, that's true, but in combination with a Caddy admin endpoint it can be used to give an attacker full access to your local network. You could have a blind SSRF vulnerability in an application and while that's not great, it is difficult for an attacker to exploit successfully. If the attacker knows or guesses you're hosting Caddy on the same machine, they know you most likely have an admin interface on localhost:2019 that they can use to make further local network requests and also makes it possible for them to access the results of their local network requests they were making through the blind SSRF vulnerability hypothesised above. Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it, see: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
      - francislavoie 3y ago
        > Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it Actually, most everyone wants zero-downtime config reloads. The API is necessary to perform config reloads. As others have said, you may use a unix socket instead for the admin endpoint. And see https://news.ycombinator.com/item?id=37482096 https://news.ycombinator.com/item?id=37482096, we plan to make that the default in certain distributions.
        yencabulator 3y ago
        > The API is necessary to perform config reloads. Of course it isn't. It could reload the config from the same path it loaded the config from in the first place. Like practically all other software has done for decades.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]