Created attachment 1220 [details] Nessus screenshot Nessus is at it again and complains if a web server doesn't set X-Frame-Options or Content-Security-Policy. This provides protection against clickjacking on sites that maintain a login (e.g. using session cookies). Since we don't maintain logins, there is nothing to protect in ThinLinc by adding these. But users still want to avoid having warnings from Nessus, so it would be good if we could include those headers.
Note that adding such headers would prevent embedding Web Access or Web Admin, so we need to consider bug 5231 and bug 8191 as well.
Based on findings from bug 7948, a Nessus scan flagged a new medium-severity issue "SSL Anonymous Cipher Suites Supported", https://www.tenable.com/plugins/nessus/31705, after configuring HSTS which had not appeared before. In addition, after the HSTS configuration a total of 17 new "Info" report entries were added. See bug 7948 comment 45 and also the attachments in bug 7948 comment 35 for more details.
We performed some preliminary testing, sending the Content-Security-Policy header with the directive frame-ancestors set to 'none'. This appears to be working as intended, as neither webaccess nor webadmin login prompts are displayed when embedded in an iframe. The browser -- in this case Firefox -- is reporting that it cannot display the embedded site for security reasons. We can also confirm that the header is sent. Moreover, under non-embedded circumstances, things are working as usual. However, we have not yet been able to reproduce the Nessus security error report as seen in attachment 1220 [details]. We are looking into configuring Nessus for this purpose to confirm that it won't complain about this anymore.
Additional tests have been performed with Nessus to reproduce the security warning. The following has been noted: - Ubuntu 22.04: When scanning web access running on Ubuntu 22.04, we receive the warning 50345 "Missing or Permissive X-Frame-Options HTTP Response Header". The X-Frame-Options header is deprecated but was historically used to control whether a website allows itself to be embedded within an HTML frame on another site. This missing or permissive X-Frame-Options header could allow clickjacking attacks. - Fedora 39: When scanning web access running on Fedora 39, we receive the warning 85582 - "Web Application Potentially Vulnerable to Clickjacking", which is the warning our customers have pointed out as an issue. Based on these results, it appears that Nessus runs its tests sequentially, for example that it first determines the operating system and then selects a subset of plugins relevant to that OS (for example avoiding the execution of Linux-specific plugins on a Windows server). This may explain the different warnings generated during the scans of Web Access on Ubuntu and Fedora, despite both services having the same configurations.
We decided to disregard embedding for now, the main focus here is to silence scanners. Enabling embedding will be handled later in bug 5231 and bug 8191. That means there is no need to have any configuration for this. We can send this header unconditionally. Noted on bug 8191 that this will have to change if we want to allow embedding.
The solution right now is to only send "Content-Security-Policy: frame-ancestors 'none';". We could also send the deprecated X-Frame-Options, but we found this redundant when sending the frame-ancestors directive. There are several more directives to Content-Security-Policy that could potentially be caught in a scan in the future, but we have decided not to look more into those right now. We focus on satisfying the scanners that we know of today.
(In reply to Frida Flodin from comment #9) > The solution right now is to only send "Content-Security-Policy: > frame-ancestors 'none';". > > We could also send the deprecated X-Frame-Options, but we found this > redundant when sending the frame-ancestors directive. After further discussions we changed our approach slightly. Some tests showed that Nessus complains about XFO (50345) even if we send the CSP header. In order to silence the XFO-log (50345), we also need to send the XFO-header. Aside from the Nessus complaint, there are three more reasons: - Old browsers doesn't support the CSP header. - Sending X-Frame-Options doesn't do any harm for new browsers that supports CSP headers. - We've seen that other websites send both headers.
We have now tried sending both the CSP (Content-Security-Policy) header and XFO (X-Frame-Options) header by scanning two different machines (mentioned in comment 7). We ran three different types of scans: - The first one was without any extra headers. - The second scan was when the CSP header was set. - The third scan included both the CSP and XFO headers. From the first scan, we noted that Nessus complained about clickjacking (85582) as mentioned in comment 7. The same result was seen when scanning a RHEL 9 machine. On Ubuntu it only complained about XFO (50345). In the second scan, the clickjacking-warning (85582) was gone, but a new info-log appeared (50345). Note that the 50345 log was the same as seen on Ubuntu 22.04 in the first scan. On Ubuntu, the XFO complaint (50345) remained. The results from the third scan showed that both complaints (85582, 50345) were gone.
Aside from CSP and XFO, we also made some effort to look into three more headers: * X-Content-Type-Options [1] * Referrer-Policy [2] * Permissions-Policy [3] The reason we looked at these headers is that the web-site scanner securityheaders.com complains about these. * In short, the “X-Content-Type-Options: nosniff” header aims to ensure that the MIME type in the “Content-Type” header is followed and not changed. * The purpose of the “Referrer-Policy” header is to control how much information is sent with the referer-header. * The “Permissions-Policy” header provides a mechanism to allow and deny the use of browser features in a web app. Some comparisons with other websites that should care about being secure, such as banking websites, show that at least the X-Content-Type-Options header is widely used. All of swedbank.se, handelsbanken.se, and nordea.se lack the Referrer-Policy and Permissions-Policy headers. Despite this, the Security Headers scanner gives these sites an A-rating. We decided that, given how these headers are used by others, we will only continue investigating X-Content-Type-Options. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy
The report from the most recent Nessus scan, mentioned in comment 11, is available in attachment 1242 [details]. It’s important to note that there remains a low-severity security warning: 42057 - Web Server Allows Password Auto-Completion. This issue could be resolved by adding the autocomplete="off" attribute to login fields. However, it’s worth noting that most modern browsers and password managers now ignore autocomplete="off" for login fields, as password managers are generally seen as a security benefit. Users tend to use stronger passwords when they don’t have to remember them. If it's important for a user not to save login credentials (for example, when using a public computer), there’s always the option to use incognito mode for web services.
Regarding X-Content-Type-Options (XCTO), one concern that surfaced immediately was — what happens if we accidentally have set the wrong Content-Type? Will the XCTO header cause the browser to block it somehow? Some simple tests show that if we send an HTML page with "Content-Type: image/png" the browser will refuse to load the page, even if we don't send the XCTO header. However, in some cases, browsers will do content sniffing [1] to guess the MIME type. This is done to compensate for incorrect metadata in the Content-Type. If the XCTO header is sent, these guesses are disabled. Ensuring that we don't have the wrong Content-Type would require thorough testing. Furthermore, there are a few more reasons to not send this header: * The scanner that we've heard most about, Nessus, doesn't complain about this header. * Some big web apps, such as Slack, do not send it. * The two attacks mentioned in [2] do not seem relevant. Regarding the MIME confusion attack, Web Access or Web Administration do not allow untrusted users to post or comment on things. Regarding the unauthorized hotlinking attack, the point seems to be that external actors can link to resources and use them in a way that wasn't intended by the web server. In our case, we don't think we have anything of interest for someone to link to.. * Lastly, if this header is desired by a customer, they can still get it by using a proxy in front of our web services. In conclusion, we will not include this header right now. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/MIME_types#mime_sniffing [2] https://stackoverflow.com/questions/18337630/what-is-x-content-type-options-nosniff
> MUST: > > * Web security scanners (such as Nessus) must not report clickjacking > vulnerabilities about our web services Works well! This was verified in comment 11. ---------------------------------------------- > * Web services should function as before in absence of any embedding Testing was performed with build 3730 in Firefox 131 on a Fedora 40, Safari 17.5 on Mac 14.5 and in both Microsoft Edge 129 and Chrome 129 on Windows 11. In all browsers, both Web Access and Web Administration work as expected: ✓ Web Access: page loaded and login worked. ✓ Web Administration: pages load and we verified that things work in general. ✓ The new headers are present in every response from our web servers. ---------------------------------------------- > SHOULD: > > * It should be apparent to the user that embedding is prohibited Testing was performed to verify blocked embedding for Web Access and Web Administration within an <iframe> when sending the two new headers Content-Security-Policy (CSP) and X-Frame-Options (XFO). The testing was performed with build 3730 in Firefox 131 on a Fedora 40, Safari 17.5 on Mac 14.5 and in both Microsoft Edge 129 and Chrome 129 on Windows 11. --- Firefox: Worked really well. Tested a combination of the new headers (CSP and XFO) together with hsts. The new headers showed in the network tab, and this helpful error was shown to the user: > Firefox Can't Open This Page > > To protect your security, lab-245 will not allow Firefox to display the page > if another site has embedded it. To see this page, you need to open it in a > new window. --- Safari: Worked as expected, the headers showed in the network tab in the embedding scenario. However, Safari didn't show any error to the user. The only error we could find was in the browser console log, in the developer tools, this error message was printed: > Refused to load lab-245.lkpg.cendio.se:300 because it does not appear in the > frame-ancestors directive of the Content Security Policy. --- Edge: expected behavoiur, the <iframe> contents were blocked. Unlike Chrome, Edge showed the two new headers in the network tab in this scenario. In place of the <iframe> content, Edge showed this error to the user: > lab-245 refused to connect. --- Chrome: expected behaviour, did not see the two new headers in the network tab when visiting a website with Web Access/Web Admin embedded in an <iframe>. However, Chrome showed this error for the user in place of the <iframe> content: > The webpage at lab-245:300 might be temporary down or may have moved > permanently to a new web address. --- Verified and all good! Closing...
