Closed totoadd closed 1 month ago
Hi @totoadd. Could you please share your nginx config file(s)? Redact any sensitive values like host URLs.
Hello, thanks for your answer.
Here is my Nginx Proxy Manager configuration for my Nextcloud instance :
In the Details tab :
In the SSL tab :
I also added this in the Advanced tab :
location = / {
proxy_pass http://$server:$port;
add_header X-Robots-Tag "noindex, nofollow, nosnippet, noarchive";
}
location = /robots.txt {
return 200 "User-agent: *\nDisallow: /\n";
}
Have a good evening
Turn off Cache assets and try again please.
Is it possible to export the config file generated from the graphical interface options?
I turned off Cache assets option and I have retrieved the configuration file stored in the Nginx Proxy Manger folders, here it is :
server {
set $forward_scheme http;
set $server "mycloud-nextcloud.ix-mycloud.svc.cluster.local";
set $port 80;
listen 80;
#listen [::]:80;
listen 443 ssl http2;
#listen [::]:443;
server_name mycloud.example.com;
# Let's Encrypt SSL
include conf.d/include/letsencrypt-acme-challenge.conf;
include conf.d/include/ssl-ciphers.conf;
ssl_certificate /etc/letsencrypt/live/npm-6/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/npm-6/privkey.pem;
# Block Exploits
include conf.d/include/block-exploits.conf;
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security "max-age=63072000; preload" always;
# Force SSL
include conf.d/include/force-ssl.conf;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
access_log /data/logs/proxy-host-1_access.log proxy;
error_log /data/logs/proxy-host-1_error.log warn;
location = / {
proxy_pass http://$server:$port;
add_header X-Robots-Tag "noindex, nofollow, nosnippet, noarchive";
}
location = /robots.txt {
return 200 "User-agent: *\nDisallow: /\n";
}
location / {
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security "max-age=63072000; preload" always;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
# Proxy!
include conf.d/include/proxy.conf;
}
# Custom
include /data/nginx/custom/server_proxy[.]conf;
}
I also give you the included conf files :
letsencrypt-acme-challenge.conf
# Rule for legitimate ACME Challenge requests (like /.well-known/acme-challenge/xxxxxxxxx)
# We use ^~ here, so that we don't check other regexes (for speed-up). We actually MUST cancel
# other regex checks, because in our other config files have regex rule that denies access to files with dotted names.
location ^~ /.well-known/acme-challenge/ {
# Since this is for letsencrypt authentication of a domain and they do not give IP ranges of their infrastructure
# we need to open up access by turning off auth and IP ACL for this location.
auth_basic off;
auth_request off;
allow all;
# Set correct content type. According to this:
# https://community.letsencrypt.org/t/using-the-webroot-domain-verification-method/1445/29
# Current specification requires "text/plain" or no content header at all.
# It seems that "text/plain" is a safe option.
default_type "text/plain";
# This directory must be the same as in /etc/letsencrypt/cli.ini
# as "webroot-path" parameter. Also don't forget to set "authenticator" parameter
# there to "webroot".
# Do NOT use alias, use root! Target directory is located here:
# /var/www/common/letsencrypt/.well-known/acme-challenge/
root /data/letsencrypt-acme-challenge;
}
# Hide /acme-challenge subdirectory and return 404 on all requests.
# It is somewhat more secure than letting Nginx return 403.
# Ending slash is important!
location = /.well-known/acme-challenge/ {
return 404;
}
ssl-ciphers.conf
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:50m;
# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;
block-exploits.conf
## Block SQL injections
set $block_sql_injections 0;
if ($query_string ~ "union.*select.*\(") {
set $block_sql_injections 1;
}
if ($query_string ~ "union.*all.*select.*") {
set $block_sql_injections 1;
}
if ($query_string ~ "concat.*\(") {
set $block_sql_injections 1;
}
if ($block_sql_injections = 1) {
return 403;
}
## Block file injections
set $block_file_injections 0;
if ($query_string ~ "[a-zA-Z0-9_]=http://") {
set $block_file_injections 1;
}
if ($query_string ~ "[a-zA-Z0-9_]=(\.\.//?)+") {
set $block_file_injections 1;
}
if ($query_string ~ "[a-zA-Z0-9_]=/([a-z0-9_.]//?)+") {
set $block_file_injections 1;
}
if ($block_file_injections = 1) {
return 403;
}
## Block common exploits
set $block_common_exploits 0;
if ($query_string ~ "(<|%3C).*script.*(>|%3E)") {
set $block_common_exploits 1;
}
if ($query_string ~ "GLOBALS(=|\[|\%[0-9A-Z]{0,2})") {
set $block_common_exploits 1;
}
if ($query_string ~ "_REQUEST(=|\[|\%[0-9A-Z]{0,2})") {
set $block_common_exploits 1;
}
if ($query_string ~ "proc/self/environ") {
set $block_common_exploits 1;
}
if ($query_string ~ "mosConfig_[a-zA-Z_]{1,21}(=|\%3D)") {
set $block_common_exploits 1;
}
if ($query_string ~ "base64_(en|de)code\(.*\)") {
set $block_common_exploits 1;
}
if ($block_common_exploits = 1) {
return 403;
}
## Block spam
set $block_spam 0;
if ($query_string ~ "\b(ultram|unicauca|valium|viagra|vicodin|xanax|ypxaieo)\b") {
set $block_spam 1;
}
if ($query_string ~ "\b(erections|hoodia|huronriveracres|impotence|levitra|libido)\b") {
set $block_spam 1;
}
if ($query_string ~ "\b(ambien|blue\spill|cialis|cocaine|ejaculation|erectile)\b") {
set $block_spam 1;
}
if ($query_string ~ "\b(lipitor|phentermin|pro[sz]ac|sandyauer|tramadol|troyhamby)\b") {
set $block_spam 1;
}
if ($block_spam = 1) {
return 403;
}
## Block user agents
set $block_user_agents 0;
# Disable Akeeba Remote Control 2.5 and earlier
if ($http_user_agent ~ "Indy Library") {
set $block_user_agents 1;
}
# Common bandwidth hoggers and hacking tools.
if ($http_user_agent ~ "libwww-perl") {
set $block_user_agents 1;
}
if ($http_user_agent ~ "GetRight") {
set $block_user_agents 1;
}
if ($http_user_agent ~ "GetWeb!") {
set $block_user_agents 1;
}
if ($http_user_agent ~ "Go!Zilla") {
set $block_user_agents 1;
}
if ($http_user_agent ~ "Download Demon") {
set $block_user_agents 1;
}
if ($http_user_agent ~ "Go-Ahead-Got-It") {
set $block_user_agents 1;
}
if ($http_user_agent ~ "TurnitinBot") {
set $block_user_agents 1;
}
if ($http_user_agent ~ "GrabNet") {
set $block_user_agents 1;
}
if ($block_user_agents = 1) {
return 403;
}
force-ssl.conf
if ($scheme = "http") {
return 301 https://$host$request_uri;
}
proxy.conf
add_header X-Served-By $host;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Scheme $scheme;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass $forward_scheme://$server:$port$request_uri;
Since last week, the bug hasn't recurred, but I don't know if it will.
The cause of your issue is likely this:
That appears to be what the Cached Assets option of Nginx proxy manager enables.
It's NPM specific (not a standard nginx config). Stripping Set-Cookie
can be dangerous if not done very carefully.
It could cause the behavior you are describing.
Follow-up: There's a chance I'm wrong, but when I saw that proxy_ignore_headers
line that included Set-Cookie
I got deeply suspicious. I haven't reviewed NPM's config templates in depth.
Right, this instructs the fastcgi cache to cache responses despite the set-headers cookie. So multiple users receive the same same, cached cookie headers and therefore share a session.
So this issue is caused by the Cache assets option from Nginx Proxy Manager that enable proxy_ignore_headers Set-Cookie. For this reason, I disabled the Cache assets in Nginx Proxy Manager. Thank for your time passed in helping me to resolve my issue. Have a good day.
I'm going to close this out since this isn't a bug in Nextcloud, but a deployment / configuration matter. However there is a PR under early development that would add a setup check to warn the admin if we detect obvious signs of this configuration mishap. I think that would be a good addition.
⚠️ This issue respects the following points: ⚠️
Bug description
Hello, sorry for my bad english I have a Nextcloud server installed on my NAS based on TrueNAS Scale. Nextcloud is behind Nginx Proxy Manager, which is also hosted on my NAS. I have three other users on my Nextcloud server. My account has a strong 40 characters password and Two Authentification through TOTP enabled. Today, one user loaded the Nextcloud page (this browser is Brave), but instead of being connected to him account, he was connected to the admin account, so my account. He has access to the full account privileges and files without giving any username, password and TOTP. I specified that the user was yesterday connected to his account and this bug appears today then he wants to access Nextcloud. I didn't know why he had been automatically connected to my admin account by simply loading the page.
Steps to reproduce
Expected behavior
The user is not connected to the admin account but only to his own account. And it is not possible to access an account without an username, password and a TOTP code.
Installation method
Community Docker image
Nextcloud Server version
27
Operating system
Other
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
The user who discovered the bug is using the Brave browser. My NAS is working on TrueNAS SCALE 22.12 The Nextcloud instance is on Internet behind Nginx Proxy Manager.