Http Header Information Leak

Description

Hi All,

I was doing some security scans of our NextCloud 25.0.4 installation also tested on NC 26, with an online scan tool and noticed that is was showing information about the structure of our setup just by scanning the login page. I then did a separate page request with insomnia, to see the raw information was being sent to the client and noticed a few items that probably should not be sent to a non authenticated user.

HTTP Response Header

HTTP/2 200 
server: nginx
date: Sun, 19 Mar 2023 21:04:53 GMT
content-type: text/html; charset=UTF-8
content-length: 18135
vary: Accept-Encoding
set-cookie: oclg54wtpcka=gidiobtilv9a7anbig5a6qf29m; path=/; secure; HttpOnly; SameSite=Lax
expires: Sun, 19 Mar 2023 21:05:53 GMT
pragma: no-cache
cache-control: max-age=60
x-request-id: boTH3reSHwVNiSJdR7Lu
content-security-policy: default-src 'none';base-uri 'none';manifest-src 'self';script-src 'self' blob:;style-src 'self' 'unsafe-inline';img-src 'self' data: blob: https://*.tile.openstreetmap.org;font-src 'self' data:;connect-src 'self' blob: stun.(sanitized).com:443 ncs1.(sanitized).com wss://ncs1.(sanitized).com;media-src 'self' blob:;frame-src 'self' nc:;child-src blob: 'self';frame-ancestors 'self';worker-src blob: 'self';form-action 'self'
feature-policy: autoplay 'self';camera 'self';fullscreen 'self';geolocation 'none';microphone 'self';payment 'none'
x-robots-tag: noindex, nofollow
strict-transport-security: max-age=31536000; includeSubDomains; preload;
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block

As you can see from the content-security-policy section, the server returns information that the talk app is installed and which servers are being used for STUN, TURN and Signaling. Since this information was provided to a unauthenticated user, it could be used for information gathering for a attack but a bad actor. This information would be very easy to miss use if a vulnerability was discovered in the future in either the coturn server or any of the HPB Signaling services like (Janus, Nats, or Signaling Server).

Although, we have tried to minimize our attack exposure by setting the HPB to respond only to requests to a specific domain, giving up this information to unauthenticated users basically nulls that effort.

I think this information should be stripped from all public facing links like the login page, and only offered once the user is authenticated.

Also I noticed that the installations Instance ID is actually used in the cookie string, and although I am not aware of a attack vector that this could be missed used for at the moment, I'm sure someone out there will find one eventually, so it might be a good idea not to send that to unauthenticated users also, or to have NC uses a separate ID just for cookies.

I know these are minor on the grand scale of things, but I think the less information that is publicly exposed the better. Since in today's world you can hack a security company with an unpatched PLEX server.

Thanks Sebastian

Steps to reproduce

Perform a request to the login page with curl or a program like Insomnia and read the headers.

Expected behavior

Do not send STUN, TURN or Signaling Server information until user is authenticated.

Start by reproducing the login-page response with curl or Insomnia and compare the CSP, cookies, and other headers before and after authentication. Trace where the unauthenticated response receives STUN, TURN, Signaling Server, and instance-identifying information; done means the expected headers and cookie behavior are verified for both unauthenticated and authenticated requests.