Skip to content
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

X-Content-Type headers sent twice - modHeadersAvailable not set #16938

Closed
Harmageddon opened this issue Aug 30, 2019 · 4 comments · Fixed by #19002
Closed

X-Content-Type headers sent twice - modHeadersAvailable not set #16938

Harmageddon opened this issue Aug 30, 2019 · 4 comments · Fixed by #19002
Labels
3. to review Waiting for reviews enhancement
Milestone

Comments

@Harmageddon
Copy link

Copied from #8207 (comment)

I'm running NextCloud 16.0.4 on Apache/2.4.39, PHP 7.2 CGI/FastCGI. For me, the headers are sent twice - once from the .htaccess and once from here:

if(getenv('modHeadersAvailable') !== 'true') {
header('Referrer-Policy: no-referrer'); // https://www.w3.org/TR/referrer-policy/
header('X-Content-Type-Options: nosniff'); // Disable sniffing the content type for IE
header('X-Download-Options: noopen'); // https://msdn.microsoft.com/en-us/library/jj542450(v=vs.85).aspx

Normally, this line should avoid running into the case shown above:

SetEnv modHeadersAvailable true

But the environment variable can't be retrieved by getenv and is not shown in a phpinfo either. Apparently, in some environments, only environment variables starting with HTTP_ can be set in the .htaccess. I tried it and if I change the variable to e.g. HTTP_MOD_HEADERS_AVAILABLE, it works in phpinfo as well as in the response.php.

Maybe someone who has more experience with Apache / PHP-CGI can tell whether this might be a solution for at least some of the issues discussed here?

Steps to reproduce

  1. Navigate to https://cloud.zweiiconkram.de/index.php/settings/admin/overview
  2. Look at the messages displayed there, and inspect the header information returned by the server.

Expected behaviour

The headers like X-Content-Type-Options: nosniff should be transmitted exactly once. No messages warning about these headers should be displayed. modHeadersAvailable should be set to true in the .htaccess.

Actual behaviour

The headers are sent twice. Once here:

server/.htaccess

Lines 16 to 21 in 9d6eb2d

Header always set X-Download-Options "noopen"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Permitted-Cross-Domain-Policies "none"
Header always set X-Robots-Tag "none"
Header always set X-XSS-Protection "1; mode=block"
SetEnv modHeadersAvailable true

and once here:

if(getenv('modHeadersAvailable') !== 'true') {
header('Referrer-Policy: no-referrer'); // https://www.w3.org/TR/referrer-policy/
header('X-Content-Type-Options: nosniff'); // Disable sniffing the content type for IE
header('X-Download-Options: noopen'); // https://msdn.microsoft.com/en-us/library/jj542450(v=vs.85).aspx

The environment variable modHeadersAvailable doesn't exist.

If I change the server from CGI/FastCGI to FPM, neither modHeadersAvailable nor HTTP_MOD_HEADERS_AVAILABLE can be accessed by PHP - they seem to be prefixed with REDIRECT_. But FPM somehow seems to avoid sending the same headers twice, so the issue doesn't visibly appear there. However, I would not regard this as a solution to the problem, because the intended behaviour (not running into the if case if the headers have been sent by .htaccess) doesn't apply.

Server configuration

Operating system: Linux x86_64

Web server: Apache/2.4.39

Database: MySQL 5.6.19

PHP version: 7.2.11, CGI/FastCGI

Nextcloud version: 16.0.4

Updated from an older Nextcloud/ownCloud or fresh install: Continuously updated, starting from probably 11 or 12.

Where did you install Nextcloud from: https://nextcloud.com/install/#instructions-server

Signing status:

Signing status
No errors have been found.

List of activated apps:

App list
Enabled:
  - accessibility: 1.2.0
  - activity: 2.9.1
  - bruteforcesettings: 1.4.0
  - cloud_federation_api: 0.2.0
  - comments: 1.6.0
  - dav: 1.9.2
  - federatedfilesharing: 1.6.0
  - federation: 1.6.0
  - files: 1.11.0
  - files_pdfviewer: 1.5.0
  - files_rightclick: 0.15.1
  - files_sharing: 1.8.0
  - files_texteditor: 2.8.0
  - files_trashbin: 1.6.0
  - files_versions: 1.9.0
  - files_videoplayer: 1.5.0
  - firstrunwizard: 2.5.0
  - gallery: 18.3.0
  - logreader: 2.1.0
  - lookup_server_connector: 1.4.0
  - nextcloud_announcements: 1.5.0
  - notifications: 2.4.1
  - oauth2: 1.4.2
  - occweb: 0.0.4
  - password_policy: 1.6.0
  - previewgenerator: 2.1.0
  - privacy: 1.0.0
  - provisioning_api: 1.6.0
  - recommendations: 0.4.0
  - serverinfo: 1.6.0
  - sharebymail: 1.6.0
  - support: 1.0.0
  - survey_client: 1.4.0
  - systemtags: 1.6.0
  - theming: 1.7.0
  - twofactor_backupcodes: 1.5.0
  - twofactor_u2f: 3.0.1
  - updatenotification: 1.6.0
  - viewer: 1.1.0
  - workflowengine: 1.6.0
Disabled:
  - admin_audit
  - encryption
  - files_external
  - user_ldap

Nextcloud configuration:

Config report
{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.zweiiconkram.de"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "http:\/\/cloud.zweiiconkram.de",
        "dbtype": "mysql",
        "version": "16.0.4.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "UTC",
        "installed": true,
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "tempdirectory": ".../tmp\/nextcloud",
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "ssl",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "app_install_overwrite": [
            "occweb"
        ]
    }
}

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Mozilla Firefox 68.0.1

Operating system: Manjaro Linux

@Harmageddon Harmageddon added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Aug 30, 2019
@jookk
Copy link

jookk commented Aug 30, 2019

I had this, because I had one in .htaccess and one in /etc/apache2/sites-available/host.conf
deleted it from host.conf, restarted apache2 and ok now.

@Harmageddon
Copy link
Author

@jookk It's a shared webhoster, so I don't have access to the apache config, but I'm pretty sure that the two places mentioned above (.htaccess and response.php) are where the headers come from in my case. If I disable both of them, I don't see any of the headers. And if I change the environment variable to HTTP_MOD_HEADERS_AVAILABLE instead of modHeadersAvailable, the headers are sent only once and everything is fine.

zertrin added a commit to zertrin/nextcloud-server that referenced this issue Jan 19, 2020
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts.
Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area.
Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top.
See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017
zertrin added a commit to zertrin/nextcloud-server that referenced this issue Jan 19, 2020
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts.
Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area.
Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top.
See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017

Signed-off-by: zertrin <zertrin@gmail.com>
zertrin added a commit to zertrin/nextcloud-server that referenced this issue Jan 19, 2020
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts.
Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area.
Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top.
See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017

Signed-off-by: Marc Gallet <zertrin@gmail.com>
zertrin added a commit to zertrin/nextcloud-server that referenced this issue Jan 19, 2020
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts.
Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area.
Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top.
See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017

Signed-off-by: zertrin <zertrin@gmail.com>
zertrin added a commit to zertrin/nextcloud-server that referenced this issue Jan 20, 2020
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts.
Using "set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area.
Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top.
See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017

Signed-off-by: zertrin <zertrin@gmail.com>
zertrin added a commit to zertrin/nextcloud-server that referenced this issue Jan 28, 2020
The headers might already be set by the system administrator at the http server
level (apache or nginx) for some or all virtualhosts.

Using "always set" in the .htaccess of Nextcloud leads to the situation where
the headers might be set twice (once in the default 'onsuccess' table and once
in the 'always' table)! Which leads to warnings in the admin area.

Adding "onsuccess unset" solves the problem, and forces the header in
the 'onsucess' table to be unset, and the header in the 'always' table to be set.

NOTE: with this change, Nextcloud overrides whatever the system administrator
might have already set

See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002

Signed-off-by: zertrin <zertrin@gmail.com>
zertrin added a commit to zertrin/nextcloud-server that referenced this issue Jan 28, 2020
The headers might already be set by the system administrator at the http server
level (apache or nginx) for some or all virtualhosts.

Using "always set" in the .htaccess of Nextcloud leads to the situation where
the headers might be set twice (once in the default 'onsuccess' table and once
in the 'always' table)! Which leads to warnings in the admin area.

Adding "onsuccess unset" solves the problem, and forces the header in
the 'onsucess' table to be unset, and the header in the 'always' table to be set.

NOTE: with this change, Nextcloud overrides whatever the system administrator
might have already set

See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002

Signed-off-by: zertrin <zertrin@gmail.com>
@rahra
Copy link

rahra commented Feb 18, 2020

Same here, Apache 2.4.38 with mod_php. In my server configuration I set nosniff and sameorigin by default in conf-enabled/security.conf.

With the upgrade from Nextcloud 16 to 17 the default .htaccess-File was changed to force setting of the X- headers with the always keyword.

14,19c14,20
<     Header set X-Content-Type-Options "nosniff"
<     Header set X-XSS-Protection "1; mode=block"
<     Header set X-Robots-Tag "none"
<     Header set X-Download-Options "noopen"
<     Header set X-Permitted-Cross-Domain-Policies "none"
<     Header set Referrer-Policy "no-referrer"
---
>     Header always set Referrer-Policy "no-referrer"
>     Header always set X-Content-Type-Options "nosniff"
>     Header always set X-Download-Options "noopen"
>     Header always set X-Frame-Options "SAMEORIGIN"
>     Header always set X-Permitted-Cross-Domain-Policies "none"
>     Header always set X-Robots-Tag "none"
>     Header always set X-XSS-Protection "1; mode=block"
33,44d33

Removing always fixes this issue.

@ogmueller
Copy link

Another idea would be to use setifempty on some of the values. Maybe an admin wants to tweak those values without disabling the .htaccess completely.

zertrin added a commit to zertrin/nextcloud-server that referenced this issue Mar 5, 2020
The headers might already be set by the system administrator at the http server
level (apache or nginx) for some or all virtualhosts.

Using "always set" in the .htaccess of Nextcloud leads to the situation where
the headers might be set twice (once in the default 'onsuccess' table and once
in the 'always' table)! Which leads to warnings in the admin area.

Adding "onsuccess unset" solves the problem, and forces the header in
the 'onsucess' table to be unset, and the header in the 'always' table to be set.

NOTE: with this change, Nextcloud overrides whatever the system administrator
might have already set

See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002

Signed-off-by: zertrin <zertrin@gmail.com>
zertrin added a commit to zertrin/nextcloud-server that referenced this issue Mar 5, 2020
The headers might already be set by the system administrator at the http server
level (apache or nginx) for some or all virtualhosts.

Using "always set" in the .htaccess of Nextcloud leads to the situation where
the headers might be set twice (once in the default 'onsuccess' table and once
in the 'always' table)! Which leads to warnings in the admin area.

Adding "onsuccess unset" solves the problem, and forces the header in
the 'onsucess' table to be unset, and the header in the 'always' table to be set.

NOTE: with this change, Nextcloud overrides whatever the system administrator
might have already set

See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002

Signed-off-by: zertrin <zertrin@gmail.com>
@MichaIng MichaIng added enhancement 3. to review Waiting for reviews and removed bug 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Mar 5, 2020
@MichaIng MichaIng added this to the Nextcloud 19 milestone Mar 5, 2020
backportbot-nextcloud bot pushed a commit that referenced this issue Apr 25, 2020
The headers might already be set by the system administrator at the http server
level (apache or nginx) for some or all virtualhosts.

Using "always set" in the .htaccess of Nextcloud leads to the situation where
the headers might be set twice (once in the default 'onsuccess' table and once
in the 'always' table)! Which leads to warnings in the admin area.

Adding "onsuccess unset" solves the problem, and forces the header in
the 'onsucess' table to be unset, and the header in the 'always' table to be set.

NOTE: with this change, Nextcloud overrides whatever the system administrator
might have already set

See github issues #16893 #16476 #16938 #18017 and discussion in PR #19002

Signed-off-by: zertrin <zertrin@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. to review Waiting for reviews enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants