Validating when webmaster has added security.txt or other files to the system.
This should be added to the admin section. Optional using occ.
Validating when webmaster has added security.txt or other files to the system.
This should be added to the admin section. Optional using occ.
Can you elaborate on your post?
I had added a .well-known directory and files like security.txt but the system (nextcloud) give errror reports that the files are corrupt. Some kind of checksum.
So you need it to get it somehow validated, so the files stay when updated.
Thus need some tool to do so.
Understand the issue now.
Nextcloud has an integrity check that checks if there are files in the installation directory that are not from Nextcloud.
This is a security feature.
If extra files are needed, then you can install Nextcloud in a subdirectory of the web server and not put the extra files there. This is an idea.
The question is:
How to add a security.txt file to Nextcloud without errors?
Via Webserver konfiguration. Example for nginx:
location ~ ^\/.well-known\/security\.txt$ {
alias /path/to/your/security.txt/outside/of/your/nextcloud/path.txt;
}
Same works for Apache, but there the syntax is different.
Nice try, but that doesn’t work. 403 error.
I noticed that in the .htacces file there is some directions on the .well-known dir.
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} DavClnt
RewriteRule ^$ /remote.php/webdav/ [L,R=302]
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
RewriteRule ^ocm-provider/?$ index.php [QSA,L]
RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
Nothing about a security.txt file.
Entering:
https://cloud.robkalmeijer.nl/.well-known/security.txt
Gives:
Contact: HackerOne
Expires: 2025-02-28T23:00:00.000Z
Acknowledgments: HackerOne
Acknowledgments: Security Advisories · nextcloud/security-advisories · GitHub
Policy: HackerOne
Preferred-Languages: en
https://en.internet.nl/ gives error for security.txt:
Your web server offers a security.txt file in the right location and its content is syntactically valid. However, there are one or more recommendations for improvement.
Web server IP address | Findings |
---|---|
86.90.148.127 | security.txt retrieved from cloud.robkalmeijer.nl. |
… | Recommendation: security.txt should be digitally signed. |
Is this for real?
Rob.
Just for my understanding: did you add the security.txt file manually or is it shipped as part of Nextcloud? I do not know this file right now, so I would have to fiddle myself into it.
You posted in development. Do you want to implement this on NC server level? Or as an app? Or just help to get it running on your instance?
Chris
I wanted to add it manual but this file is virtual. See:
https://cloud.robkalmeijer.nl/.well-known/security.txt
When I use internet.nl to check the security.txt is not secure. It should be signed. This must be done by Nextcloud.
Well, the question here is: What should here be secured?
Taking the standard into account, the idea is to provide a way to report security vulnerabilities to the entity that runs a server. That would be the hoster/admin. The default security.txt file is linking this with the NC community (which might or might not be a good idea).
In any case, the signature must be provided by exactly this receiving entity (be it the admin or the NC company). The general question is should all reports be done against the NC server or individually to the admins? This is sort of a strategic decision.
The standard also does not define how to verify the signature (rendering it relatively low benefit):
When it comes to verifying the key used to generate the signature, it is always the security researcher’s responsibility to make sure the key being used is indeed one they trust.
I only see a use case if the contact was a mail address. Then the signature might be signed with the PGP key of said mail address. In fact, the standard is intentionally not clearly stating how to establish trust in a key [1, 2, 3].
This is also my problem with it.
The signature is to keep the content valid.
Verifying the key is not mention however I find a problible solution.
https://www.sidn.nl/.well-known/security.txt
Here is a DNS entry used, but how dns:c726929cd6784c1e8e0266755a0e6769b99c4019b748db550170bdc0._openpgpkey.sidn.nl is created is not clear.
https://www.robkalmeijer.nl/techniek/computer/servers/http/well-known/security/index.html
I find the file.
Thanks