Web Application Potentially Vulnerable to Clickjacking

[isgroup]

Describe the bug

BookStack is not protected against Clickjacking (HTTP headers X-Frame-Options or Content-Security-Policy are not sent).

Steps To Reproduce

curl any BookStack page, even the login/homepage, and you will not see such headers.

Expected behavior

The application should be secure by default.

Return the X-Frame-Options or Content-Security-Policy (with the 'frame-ancestors' directive) HTTP header with the page's response. This prevents the page's content from being rendered by another site when using the frame or iframe HTML tags.

Screenshots

N/A

Your Configuration (please complete the following information):

BookStack Docker Version (latest)

Additional context

The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses. This could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions.

X-Frame-Options has been proposed by Microsoft as a way to mitigate clickjacking attacks and is currently supported by all major browser vendors.

Content-Security-Policy (CSP) has been proposed by the W3C Web Application Security Working Group, with increasing support among all major browser vendors, as a way to mitigate clickjacking and other attacks. The 'frame-ancestors' policy directive restricts which sources can embed the protected resource.

Note that while the X-Frame-Options and Content-Security-Policy response headers are not the only mitigations for clickjacking, they are currently the most reliable methods that can be detected through automation. Therefore, this plugin may produce false positives if other mitigation strategies (e.g., frame-busting JavaScript) are deployed or if the page does not perform any security-sensitive transactions.

https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

https://en.wikipedia.org/wiki/Clickjacking

[codegeek1001]

Wouldn't you set this at the server level ? For example, in nginx, you can do:

add_header X-Frame-Options "SAMEORIGIN";

add_header X-XSS-Protection "1; mode=block";

add_header X-Content-Type-Options "nosniff";

[isgroup]

@codegeek1001 you can do that also in the webserver configuration, or in a reverse proxy, or just document it.

Still the safest option is to delivery the application "secure by default", in this case an header() call in the PHP code.

[ssddanbrown]

Thanks for advising @isgroup.

I can see the value in having this additional security by default. We'd have to allow an option to set the trusted domains as there are legitimate existing users using the platform within an iframe.

Think we might aswell use the CSP approach as that's the more modern way. CSP supports being defined as multiple headers so we could set a frame-ancestors specific CSP header. Not sure if that could possible cause issues for people that also define CSP on the server side though. Responsibilities do get a little messy.

[ssddanbrown]

I've just committed 92922288dd55ce0f77acc83eea9068cad28dccd9 with functionality to address this.

The CSP header will now be set, with a default value of 'self'. In addition, a new .env option is available:

ALLOWED_IFRAME_HOSTS="https://example.com https://a.example.com"

When this is set, the extra provided hosts will also be added to the header and cookies security options will also be altered to allow the third-party usage.

This will be included within the next feature release, v0.31.

Thanks again for raising @isgroup, I did not know about iframe control via CSP before.

[isgroup]

Cool @ssddanbrown ^_^