Caddy: Enhance basicauth functionality

[magikstm]

1. What version of Caddy are you running (caddy -version)?

0.9.4

2. What are you trying to do?

Testing hidden file vulnerability.

3. What is your entire Caddyfile?

None

4. How did you run Caddy (give the full command and describe the execution environment)?

Centos 7 (x64)

5. What did you expect to see?

I tried viewing files named as these listed below which are hidden:
.htaccess
.htpasswd
.test
.hidden/.test2 (folder with a hidden file)

I tested it with an hidden directory and I received a 404 (expected result):
.hidden (mentioned above)

6. What did you see instead (give full error messages and/or log)?

I saw the full content of these files.

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

Nothing special to do. Install version 0.9.4 and test.

Note

I'm new to Caddy (I've been testing it for two days). I wouldn't expect these files to be readable and viewable online. Is it a feature, is there a setting to make hidden files return a 404 or is it a security vulnerability?

I've looked at the code in caddy/caddyhttp/staticfiles/fileserver.go

I think these lines or the function called may be incorrect:
if fs.IsHidden(d) {
return http.StatusNotFound, nil
}

(*) Btw, I think the 404 on hidden directories is an undocumented feature (I couldn't find it mentioned in the docs).

May be related to #458 or #370.

[magikstm]

I just tested and if Caddy is installed in your root directory or your root directory contains your ssh keys they are viewable online by default.

Such as if they're installed in directories such as these:
.ssh/authorized_keys (which is hidden on my system)

That behavior may also be a security risk.

[mholt]

Caddy will serve static files in the root of your site, which defaults to the cwd. If you don't want Caddy to read them, don't put them in the website folder, or change the file permissions so that the Caddy user can't read them. This is certainly not a vulnerability in Caddy. Thanks for looking into it!

[magikstm]

I didn't understand at first that caddyfile commands replaces .htaccess behavior.

I've read more from the docs and understand it being as it is with any files except .htpasswd files.

I read this: https://caddyserver.com/docs/basicauth

There is no mention that .htpasswd files are viewable by default in this doc.

What is the recommended way to protect these file?

Is it using rewrite? (https://caddyserver.com/docs/rewrite)

[mholt]

I didn't understand at first that caddyfile commands replaces .htaccess behavior.

Right, Caddy isn't Apache.

I've read more from the docs and understand it being as it is with any files except .htpasswd files.

I want to rip out that functionality; I hate .htpasswd...

There is no mention that .htpasswd files are viewable by default in this doc.

Why should it? Don't put .htpasswd in your site folder if you don't want it served.

You could use rewrite, too, I guess. Whatever floats your boat. :)

[magikstm]

Thanks a lot for the answers. I really like Caddy.

I have a few sites I'm considering transferring and some of them unfortunately use .htpasswd as well as cgi.

.htpasswd, cgi and fail2ban have proven reasonably stable and secure for my budget over the years.

The fact that I can compile, understand the code a bit (I'm not a golang developer, but want to learn it this year) and that the docs are good makes caddy a really good option.

[mholt]

Thanks. I'm trying to come up with an easier replacement for .htpasswd that can integrate directly with Caddy's basic auth functionality. If you have ideas/suggestions I'd be happy to hear them. :+1:

[magikstm]

Strengths of basicauth's are:

• Ease of use
• Browser support
• Server support

Cons:

• Questionable security (vulnerable to bruteforce attacks and the .htpasswd file is a risk too)
• Lack of templating
• Speed issue with bigger files (non-issue for most sites)
• No group feature (possible with .htgroup)
• No real expiration feature (beside closing the browser)
• Logout feature is hard to implement on all browsers
• Password change for users is hard to implement
• Potential use of multiple files

It depends what you wish to improve from the current features.

OAuth, a custom solution built on something like sqlite or another solution may be a better option, but specs would have to be detailed.

[mholt]

OAuth would be a separate middleware entirely, and indeed there has been some work to integrate OAuth into Caddy as a plugin (/cc @captncraig I think was doing it).

Could you elaborate on these points? I'm not clear on them:

• Templating
• Speed issue with bigger files
• Group feature
• Why password change is hard to implement
• Potential use of multiple files

Basicauth could probably be improved with:

• Built-in rate limiting, e.g. a number of failed logins and we block the IP for some time.
• Configurable "session" expiration
• An external file listing users and passwords and maybe even authorized paths, like .htpasswd but less cryptic and maybe more powerful

[magikstm]

• Built-in rate limiting, e.g. a number of failed logins and we block the IP for some time.
  
  
  
  • That would be good. It would eliminate the need for an extra layer (and dependency) such as fail2ban that isn't that easy to configure.
  
  
• Configurable "session" expiration
  
  
  
  • Would be good too. Allowing a "logout" possibility that works accross all browser may be implemented alongside that feature. It's not a joy to develop on Apache especially for IE.
    
    Ref: http://stackoverflow.com/questions/1163868/how-to-logout-when-using-htaccess-and-htpasswd-authentication
    
    Ref: http://stackoverflow.com/questions/449788/http-authentication-logout-via-php
  
  
• An external file listing users and passwords and maybe even authorized paths, like .htpasswd but less cryptic and maybe more powerful
  
  
  
  • That would be good too.
  
  

Sure, I'll try to elaborare more on these. I'm not an expert on .htpasswd though. Maybe an intermediate level user.

Templating

.htpasswd uses browser's internals to display the prompt for login and password. PHP or another language could be used to make a more elaborate solution (with a design that is richer), but .htpasswd doesn't provide such possibilities by itself.

Speed issue with bigger files

See this: https://httpd.apache.org/docs/2.4/en/howto/auth.html#possibleproblems
(I can't confirm 100% if it applies to Caddy too, but I would believe so at least if it's http and not using http/2.)

Because of the way that Basic authentication is specified, your username and password must be verified every time you request a document from the server. This is even if you're reloading the same page, and for every image on the page (if they come from a protected directory). As you can imagine, this slows things down a little.

Group feature

BasicAuth could support groups with options such as these:

AuthUserFile "/usr/local/apache/passwd/passwords"
AuthGroupFile "/usr/local/apache/passwd/groups"
Require group GroupName`

Ref: https://httpd.apache.org/docs/2.4/en/howto/auth.html#lettingmorethanonepersonin
Ref: https://httpd.apache.org/docs/2.4/en/mod/mod_authz_groupfile.html

That's the Apache way of handling it. That usage is limited to "allowing these groups access", it doesn't provide ways to "limit" these groups differently based on these groups. Implementing this or something else would require development.

Why password change is hard to implement

BasicAuth by itself doesn't provide a way to "add", "modify" or "delete" users. It also doesn't provide a way to edit passwords. Such features would have to be implemented. Wouldn't be hard per-se, but more a tedious task as it would have to be tested on every OS.
Apache handled it this way: https://httpd.apache.org/docs/current/en/programs/htpasswd.html
That task could also be left to the application needing to use the .htpasswd file.

Potential use of multiple files

.htpasswd allows for usage such as both of these using two .htpasswd on one domain:

domain.com/protected
domain.com/admin

or

domain.com/protected/admin

Adding , modifying or removing a "basicauth" directive means having to restart Caddy or send it a "USR1":
https://caddyserver.com/docs/basicauth
Ref: https://caddyserver.com/docs/cli
If that server is a media or data server it may mean lost of connection or download for some users. It's possibly a minor issue or a non-issue with Caddy.

[jazoom]

Built-in rate limiting would be nice.

[thalesfsp]

Update on this topic?

[magikstm]

There have been some corrections or adjustments to Caddy's BasicAuth directive since then, but few new features.

I've been contributing and using loginsrv (an independent Caddy plugin) for projects in production for the past few months to get most features listed above. It is available as a plugin.