MyBB Community Forums

Full Version: Will MyBB support default-src 'self' in CSP?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi, we've been running a MyBB forum for about 5 years - thanks!

Over the past year based on the recommendation by Google and Mozilla to migrate websites to HTTPS, I've been gradually implementing all of the recommendations of the MyBB "Setting Up HTTPS" document:

https://docs.mybb.com/1.8/administration...ity/https/

We have an SSL certificate provided by our webhost, and my htaccess file looks like this:

# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Set Secure HTTP Headers
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" env=HTTPS
Header always set Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval' ; frame-ancestors 'self'; upgrade-insecure-requests; base-uri 'self'; reflected-xss block;"
Header always set X-XSS-Protection "1; mode=block;"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin"

# Hide this file
<Files .htaccess>
order allow,deny
deny from all
</Files>

# If a folder does not contain an index file, do not display content to browser
Options -Indexes


With this I've finally scored a "B" on https://observatory.mozilla.org and https://csp-evaluator.withgoogle.com

However, the reports conclude that the Content Security Policy settings required for MyBB are basically insecure, specifically the need for data: 'unsafe-inline' and 'unsafe-eval' to allow inline styles and scripts

So, my long question is this: Will MyBB 1.9 allow us to restrict the default-src, script-src, object-src (etc) settings to 'self' ?

[attachment=42073]
It's not clear yet. I'd love to give a definitive answer, but I honestly haven't looked into it at all yet - we'd need a way to replace the reasons that we currently use inline JS and styles (namely, getting PHP data into JS/CSS).
Thanks, Euan,

Google mentions "if you must..." about typical forum software being built on inline scripts with an example that echoes what you said
https://developers.google.com/web/fundam...3_ssl_only

Apparently going forward, to be fully compliant, you can specify inline with a "nonce" or a "hash" (from the same article):
https://developers.google.com/web/fundam...st_use_it_

The recommended MyBB security settings found here...
https://docs.mybb.com/1.8/administration...ty-headers

...result in this from the observatory.mozilla.org CSP evaluator (link below):
[attachment=42076]

Further reference for anyone interested - this is all about the HTTPS SSL/TLS lock on the browser, and making sure the connection is standards compliant and as secure as possible...

Mozilla's HTTPS and Content-Security-Policy guidelines
https://developer.mozilla.org/en-US/docs...ity-Policy

Scott Helme's CSP Cheat Sheet
https://scotthelme.co.uk/csp-cheat-sheet/

Create and test website https and CSP headers:
https://securityheaders.com
https://report-uri.com/home/generate
https://observatory.mozilla.org
https://csp-evaluator.withgoogle.com
I'll certainly look int it and see what we can do to improve Smile
(2019-07-31, 06:52 PM)gimbal Wrote: [ -> ]Thanks again - I appreciate the info you all provide about MyBB here.

Do you happen to know anything about the other MyBB security recommendations - specifically the HTTPS and Header set Content-Security-Protocol (CSP) directives?

To function with a CSP header, MyBB requires allowing default-src 'unsafe-inline' 'unsafe-eval' directives (to allow inline scripts), but apparently that basically defeats the purpose of having CSP? Just wondering if there is a roadmap to getting MyBB to comply with default-src 'self' which would be considered safer? Or, is this not really an issue?
(2019-07-31, 07:01 PM)gimbal Wrote: [ -> ]Google mentions that "if you must..." about typical forum software being built on inline scripts with an example that echoes what you said

https://developers.google.com/web/fundam...3_ssl_only

Apparently going forward, to be fully compliant, you can specify inline with a "nonce" or a "hash" (from the same article):

https://developers.google.com/web/fundam...st_use_it_

Yes, ideally it would be possible to disallow all inline <script>s which would mitigate complete classes of vulnerabilities.

As Euan says, there are currently hundreds of tags being included in the source code of various pages - it's possible to pass necessary data to included .js scripts, but a significant amount of such JavaScript code will require logic changes in related areas.
We'll likely start indexing all those locations and choose the best approach at some point, but it's not tied to any specific future MyBB version yet.

Meanwhile, the current Content-Security-Policy example mainly adds HTTPS-related improvements for upgrading and blocking unsecured requests. These directives should be safe to add on most MyBB installations, and similarly, depending on installed themes and plugins (what kinds of resources, and from what kinds of locations, they use), additional restrictions may be added.
Hi again, I am wondering if the example below from Github is a possible solution for adding "nonces" (Numbers Used Once) to the inline scripts and styles MyBB uses? ... with the ultimate goal of protecting MyBB with Content Security Policy, by using script-src "nonce" directives, instead of "unsafe-inline" ?

Background: Content Security Policy is about protecting websites and visitors, by blocking everything first, and then "whitelisting" only the resources that are needed. But forum software uses a lot of inline scripts and styles - So to use MyBB with a CSP, you have to specify a script-src of "unsafe-inline" that effectively opens back up much of the vulnerabilty that CSP is meant to block.

The recommended solution is to use "nonces" (Numbers Used Once) that are generated on each page request, and are inserted in to each page header as a CSP directive, and also in to the inline script or style tags, and they must match on each request for any script to run. Any attacker would have a very hard time guessing the nonce to insert their own script. The challenge is how to generate, insert, and verify the nonce reliably.

Here's an example I found on Github for Kirby software - 

https://gist.github.com/joachimesque/849...206fedc2c1


config.php

<?php
  $csp_nonce = base64_encode(random_bytes(20));
  $csp_header = "Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $csp_nonce . "';";
  c::set('csp-nonce', $csp_nonce);
  header($csp_header);

page-with-inline-script.php

<script type="text/javascript" nonce="<?= c::get('csp-nonce') ?>">
  console.log('Hello World!')
</script>
Something similar to that would work, yes.
(2019-07-29, 10:35 PM)gimbal Wrote: [ -> ]Hi, we've been running a MyBB forum for about 5 years - thanks!

Over the past year based on the recommendation by Google and Mozilla to migrate websites to HTTPS, I've been gradually implementing all of the recommendations of the MyBB "Setting Up HTTPS" document:

https://docs.mybb.com/1.8/administration...ity/https/

We have an SSL certificate provided by our webhost, and my htaccess file looks like this:

# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Set Secure HTTP Headers
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" env=HTTPS
Header always set Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval' ; frame-ancestors 'self'; upgrade-insecure-requests; base-uri 'self'; reflected-xss block;"
Header always set X-XSS-Protection "1; mode=block;"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin"

# Hide this file
<Files .htaccess>
order allow,deny
deny from all
</Files>

# If a folder does not contain an index file, do not display content to browser
Options -Indexes


With this I've finally scored a "B" on https://observatory.mozilla.org and https://csp-evaluator.withgoogle.com

However, the reports conclude that the Content Security Policy settings required for MyBB are basically insecure, specifically the need for data: 'unsafe-inline' and 'unsafe-eval' to allow inline styles and scripts

So, my long question is this: Will MyBB 1.9 allow us to restrict the default-src, script-src, object-src (etc) settings to 'self' ?


Im very pleased to find out you take security seriously on your websites. Using csp is a great way to limit attacks on your site, but its not dominate. Best way to stay on top of hackers is to do your best. Or simply dont use mybb at all and find another platform to role with. But let me tell you, most boards have scripts. Use less plugins if you are worried about vulnerability. And stay up to date on the latest board security releases. Maybe pay for a cloud dns that is third party that can help with attacks for you like cloudflare. 



If you want a site 100% unhackable
..... good luck because nothing is safe anymore.
(2020-01-27, 01:22 AM)xXMoeXx Wrote: [ -> ]Im very pleased to find out you take security seriously on your websites. Using csp is a great way to limit attacks on your site, but its not dominate. Best way to stay on top of hackers is to do your best. Or simply dont use mybb at all and find another platform to role with. But let me tell you, most boards have scripts. Use less plugins if you are worried about vulnerability. And stay up to date on the latest board security releases. Maybe pay for a cloud dns that is third party that can help with attacks for you like cloudflare. 

If you want a site 100% unhackable
..... good luck because nothing is safe anymore.

... um. OK. Why are you on the MyBB community forum telling people not to use MyBB?
(2020-01-27, 01:49 AM)gimbal Wrote: [ -> ]
(2020-01-27, 01:22 AM)xXMoeXx Wrote: [ -> ]Im very pleased to find out you take security seriously on your websites. Using csp is a great way to limit attacks on your site, but its not dominate. Best way to stay on top of hackers is to do your best. Or simply dont use mybb at all and find another platform to role with. But let me tell you, most boards have scripts. Use less plugins if you are worried about vulnerability. And stay up to date on the latest board security releases. Maybe pay for a cloud dns that is third party that can help with attacks for you like cloudflare. 

If you want a site 100% unhackable
..... good luck because nothing is safe anymore.

... um. OK. Why are you on the MyBB community forum telling people not to use MyBB?

I'm not even going to argue with you. Simply re-read what I wrote and have a better understanding of the situation. You're basically complaining about MyBB using front-end frameworks which every board uses. You're basically being asinine and nitpicking. I've been denied support because MyBB doesn't endorse hacking related content. You're basically trying to secure your site from attacks that are basic. XSS cross site scripting is easy to prevent, which MyBB platform stays on top of it. They do a better job of patching vulnerability then VBulletin which is why I switched. However, I hate there themes. Which Is why I'm porting over VB themes to Mybb to help make them better.

WAYS TO SECURE YOURSELF AGAINST BROWSER ATTACKS
  • ESCAPING - The first method you can and should use to prevent XSS vulnerabilities from appearing in your applications is by escaping user input. Escaping data means taking the data an application has received and ensuring it’s secure before rendering it for the end user. By escaping user input, key characters in the data received by a web page will be prevented from being interpreted in any malicious way. In essence, you’re censoring the data your web page receives in a way that will disallow the characters – especially < and > characters – from being rendered, which otherwise could cause harm to the application and/or users.
  • Validating Input - Validating input is the process of ensuring an application is rendering the correct data and preventing malicious data from doing harm to the site, database, and users. While whitelisting and input validation are more commonly associated with SQL injection, they can also be used as an additional method of prevention for XSS. Whereas blacklisting, or disallowing certain, predetermined characters in user input, disallows only known bad characters, whitelisting only allows known good characters and is a better method for preventing XSS attacks as well as others.
  • Sanitizing - A third way to prevent cross-site scripting attacks is to sanitize user input. Sanitizing data is a strong defense, but should not be used alone to battle XSS attacks. It’s totally possible you’ll find the need to use all three methods of prevention in working towards a more secure application. Sanitizing user input is especially helpful on sites that allow HTML markup, to ensure data received can do no harm to users as well as your database by scrubbing the data clean of potentially harmful markup, changing unacceptable user input to an acceptable format.[/i]
    Basically, the above means to make sure your code is secure. There is no absolute security concering XSS since people find new attack vectors every day. Sometimes XSS is even a browser bug you cant do anything about (excep some workarounds).You can use programs like Acunetix Vulnerability Scanner which finds known-vulnerabilities on your specific server by scanning the host and going through the code to see if there is any vulns. But, like I said.... New attacks every day so you may as well just use very little plugins like I do, use cloudflare service that helps with attacks, maybe a couple mybb security plugins, use a free trial of Acunetix to scan your host to check vulnerability's. Sucuri is another good one to help with browser attacks. Use what ever board you want, but what your asking for is a miracle.
Pages: 1 2