New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoiding misconfigurations that could lead to breaches #1967

Open
mholt opened this Issue Nov 30, 2017 · 5 comments

Comments

6 participants
@mholt
Owner

mholt commented Nov 30, 2017

As you know, one of the primary goals of Caddy is for it to be easy to configure. I strongly believe that easy configuration with sane defaults is crucial for good security. As Troy Hunt testified to US Congress today, misconfigurations and prioritizing convenience are primary causes of allowing data/security breaches.

I'm interested in looking into ways that Caddy can further help prevent accidentally making a site or service accessible to the public when it is not intended to be. It already does this to an extent by requiring a certificate by default, which requires public verification of a domain name. However, some services may use a public domain name or subdomain but are only meant to be exposed on internal interfaces.

Ways that Caddy could protect a site or service:

  • Exposed only to a local or internal interface
  • Basicauth
  • TLS client auth

There are probably others; but the point is, how can we go about reducing the likelihood of a server misconfiguration such that content which is intended only to be private is not made public?

As an example of part of a solution to help you get an idea of what might be possible, imagine typing a directive called "public" in a site block that is intended to be public (even though Caddy thinks it should be private by default for safety).

Discussion questions:

  • What are some signs in the Caddyfile, the way Caddy was run, or even HTTP requests that a site should be private?
  • How can Caddy help prevent publicly exposing private sites to the Internet?
@magikstm

This comment has been minimized.

Show comment
Hide comment
@magikstm

magikstm Dec 1, 2017

Contributor

I would consider:

  1. Requiring a root directive (to avoid a misconfiguration that may expose unwanted files)
  2. Validating that caddyfile isn't within root directive path (to avoid exposing sensitive info)
  3. Validating that a basicauth file isn't within root directive path (to avoid exposing sensitive data)
  4. Validating that errors directive files aren't within root directive path (to avoid exposing sensitive data)
  5. Validating that log directive files aren't within root directive path (to avoid exposing sensitive data)
  6. Validating that import directive path isn't within root directive path (to avoid exposing sensitive info)
Contributor

magikstm commented Dec 1, 2017

I would consider:

  1. Requiring a root directive (to avoid a misconfiguration that may expose unwanted files)
  2. Validating that caddyfile isn't within root directive path (to avoid exposing sensitive info)
  3. Validating that a basicauth file isn't within root directive path (to avoid exposing sensitive data)
  4. Validating that errors directive files aren't within root directive path (to avoid exposing sensitive data)
  5. Validating that log directive files aren't within root directive path (to avoid exposing sensitive data)
  6. Validating that import directive path isn't within root directive path (to avoid exposing sensitive info)
@OmgImAlexis

This comment has been minimized.

Show comment
Hide comment
@OmgImAlexis

OmgImAlexis Dec 4, 2017

Adding onto what @magikstm said. I'd also like to see certain known files/paths to be filtered.
For example not allowing files called passwd to be served without some kind of override in the plugin block of the Caddyfile, e.g. http.filemanager.

OmgImAlexis commented Dec 4, 2017

Adding onto what @magikstm said. I'd also like to see certain known files/paths to be filtered.
For example not allowing files called passwd to be served without some kind of override in the plugin block of the Caddyfile, e.g. http.filemanager.

@tobya

This comment has been minimized.

Show comment
Hide comment
@tobya

tobya Dec 6, 2017

Collaborator

Hiding files that begin with a . dot such as .env files by default which may contain information. This is already a feature request with a general hiding plugin.

Collaborator

tobya commented Dec 6, 2017

Hiding files that begin with a . dot such as .env files by default which may contain information. This is already a feature request with a general hiding plugin.

@geek1011

This comment has been minimized.

Show comment
Hide comment
@geek1011

geek1011 Dec 7, 2017

@tobya An exception would need to be added for RFC 5785, which is the .well-known dir. Also locations which are proxied should be exempted as well, as most would already have their own security, and blocking dotfiles could break them.

geek1011 commented Dec 7, 2017

@tobya An exception would need to be added for RFC 5785, which is the .well-known dir. Also locations which are proxied should be exempted as well, as most would already have their own security, and blocking dotfiles could break them.

@root360-AndreasUlm

This comment has been minimized.

Show comment
Hide comment
@root360-AndreasUlm

root360-AndreasUlm Jan 26, 2018

Contributor

I'd add the following to the list:

  1. prevent delivering directories of version control systems like tar-command with --exclude-vcs https://www.gnu.org/software/tar/manual/html_section/tar_48.html#IDX420
  2. prevent delivering ignore files of version control systems, e.g. tar-command excludes .cvsignore, .gitignore, .bzrignore, and .hgignore
  3. prevent delivering source code files that should be interpreted (e.g. *.php) unless a directory based option allows that
  4. might be really hard but removing tracebacks from outputs by default would improve security a lot as mostly tracebacks contain sensitive information like passwords, session data and so on
Contributor

root360-AndreasUlm commented Jan 26, 2018

I'd add the following to the list:

  1. prevent delivering directories of version control systems like tar-command with --exclude-vcs https://www.gnu.org/software/tar/manual/html_section/tar_48.html#IDX420
  2. prevent delivering ignore files of version control systems, e.g. tar-command excludes .cvsignore, .gitignore, .bzrignore, and .hgignore
  3. prevent delivering source code files that should be interpreted (e.g. *.php) unless a directory based option allows that
  4. might be really hard but removing tracebacks from outputs by default would improve security a lot as mostly tracebacks contain sensitive information like passwords, session data and so on
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment