MigrateToFlarum Lab, the health scanner for Flarum

clarkwinkelmann

I am pleased to present you a free (and open source !) online tool to check the health of your Flarum, or any other Flarum out there really.

Simply go to https://lab.migratetoflarum.com/ and enter your forum url to get started.

For now the report includes the following data:

Url check

Checks both the bare and www version of your domain on http:// and https:// protocol
Warns of unresolvable hosts or insecure settings
Warns of duplicate urls
Warns of invalid config.url setting
On https://, checks your HSTS and CSP headers

Extensions check

Shows the list of all extensions loaded on the frontend, with links to Packagist, Flagrow.io and GitHub. Only extensions adding features to the user-facing area are visible
When possible, show extension version and suggest updates if available
Warns of deprecated extensions
Some admin-only or background-only extensions might not be detected

Security check

Checks if your webserver is exposing storage or vendor folders as well as Composer files
Checks for known Flarum security vulnerabilities

Rating

Forums are awarded a rating from A (best) to D (worst):

A+: same as A, but implements recommended security headers
A: correctly configured on HTTPS
B: correctly configured on HTTPS but with deprecated extensions or suboptimal redirects
C: Invalid configuration or HTTP only
D: known security issues and/or outdated Flarum and/or vulnerable extensions

Once you fixed your issues, start a new scan to get your new rating 😉

Support

You can use my referral link to get $100 free credit with a new DigitalOcean account, and I get $25 after you spend $25, which goes directly to pay for the lab hosting https://www.digitalocean.com/?refcode=6077bb0e5aeb

Privacy / disclaimer

Use this service at your own risks.

When scanning a website you can choose to not list the results on the homepage. All reports (hidden or not) are stored on the server for an indefinite amount of time.

This service is operated by Clark Winkelmann. Please report any issue here or on the GitHub repo.

Hari

clarkwinkelmann https://lab.migratetoflarum.com/

its not working if we are in v1.0

navindra

clarkwinkelmann Wow, very very nice. It's very cool that you can detect the installed extensions... it helps to learn how some of the sites like https://outdoor.lifestyle are implemented.

Sanguine

This! What an awesome tool. I toyed with the idea of making this, but your implementation puts the bar very high ? Congrats and thanks for sharing it. I hope it will generate a lot of business for you.
Now I am off to implement CSP and HSTS headers for FreeFlarum ?

Req: would be nice if it could test for the version (ie. if patch 7.1 has been applied).

clarkwinkelmann

Sanguine thanks ?

I plan to detect the Flarum version as well, but haven't implemented it yet. Detecting beta7.1 sadly isn't possible without attempting the exploit itself, which I don't want to do ? The only way to detect 7.1 via observation only would be to look into the vendor folder, and if I can do that you have a far greater problem than not running the latest patch ?

I first started to write a parser for the vendor/composer/installed.json file but it really doesn't make sense as if I can read that file the only thing you should do it fix the webserver config immediately, hence the red message banner in the report if it is the case.

Sanguine

clarkwinkelmann About CSP, could you suggest a sane CSP for a typical forum?

clarkwinkelmann

Sanguine I'm mostly still using the ones I published here https://discuss.flarum.org/d/4788-are-you-using-csp-headers-with-flarum

The pusher extension requires a few more ones, but otherwise I think that's already a good summary.

I don't think I'll add any suggestions in the report. I'd prefer using the time to actually implement CSP into Flarum.

clarkwinkelmann

I was considering adding a rating per website to the scanner, in a similar fashion to SSLLabs or SecurityHeaders.io, but am not really sure how to do it. Any suggestion is welcome.

I guess it doesn't make sense to rate something based on the forum settings or the amount of extensions... The only thing that I think make sense is server and software security.

I was thinking of something like:

A+: same as A, but implements recommended security headers
A: correctly configured on HTTPS
B: correctly configured on HTTPS but with deprecated extensions or suboptimal redirects
C: Invalid configuration or HTTP only
D: known security issues and/or outdated Flarum and/or vulnerable extensions

gurjyot

clarkwinkelmann You can actually add a few more features and do a ranking based on few more factors.

Loading speed of website

Cashing of website

Features like Google Captcha and Askimet plugin are enabled or not

Whether website is showing any other error or not

Rest I would ask you to add one other feature to tell users about the theme a website is using. It's one of the most used features in WP so maybe one day, it'll also be a big feature here ?

Sanguine

clarkwinkelmann I made a similar scanner for Magento (sample scan) and chose to use green | orange | red as simple quality indicators. I wanted to keep it simple, as my target audience were store owners, not server admins.

I also made a test for TTFB, although that varies wildly for a server on the other side of the globe.

+1 for the proper cache headers for static assets

In the long run, as Flarum matures, there will be more security incidents and other flaws to check for (also in extensions). Right now, I think you are almost complete!

clarkwinkelmann

Update time !

Introducing proper subdomain detection and ratings ! The scanner will always try the www subdomain, but now it stays silent if it doesn't resolve but isn't required. Requirement is based on the Public Suffix List so it should work on any exotic domain but let me know if something isn't right.

The ratings works more or less as described in my message above clarkwinkelmann except it currently ignore extensions completely. It will be improved in the future.

Damn the homepage doesn't look very bright right now with the last ratings ?

clarkwinkelmann

gurjyot thanks for the suggestions !

What do you mean by "cashing" ?

If there is any critical error on the forum the report should already fail at the url scan section. I could maybe improve it further, but this will basically be a 500 error in most cases and I can't get more details than that ?

Right now there's no proper theming in Flarum so I can't really extract a name/package (other than the list of extensions). I was thinking of extracting the custom CSS. But it has limitations, as I can only see the compiled CSS and not the source LESS when scanning the forum.

gurjyot

clarkwinkelmann By caching I mean, whether the website is using browser cache properly for it's users. Since WP has separate cache plugins so it's beneficial there, but I guess it's different in case of Flarum.
In case of errors, I am not focusing on critical errors (once a stable release is out, there will be less and less critical errors every time). I am talking about small errors which are sometimes missed by website owners and your website can be used to detect them.

Yeah there is no proper theme in Flarum right now, so this can be left for future use. Although I would suggest not to make anything which can show CSS and LESS because if someone is using custom design for it's website (not to be used by others) and others use that design using your website. Then the second party can be liable for copyright issues.

clarkwinkelmann

We have passed 50 successful scans from 30 different forums !

I hope it has already helped multiple forum owners to fix their Flarum settings ?

In particular I can't emphasize enough how dangerous the exposed folders issue is. Hope every admin fixed it correctly !

Sanguine

Suggestion: the additional check for www. + domain is probably not very useful if the forum is hosted on a subdomain already (or IP). You could check for that using this list: https://publicsuffix.org/list/

clarkwinkelmann

Sanguine yes indeed. I first had some barbarian subdomain detection but I hold it back so I can implement it properly once I find the time. I planned to use that very list for that ?

Now the IP being used as a domain, that's not intended. I just noticed that earlier ? I thought I had it handled, but it looks like it isn't. I'll try to fix it soon ?

BlackSheep

Another thing I noticed is that if your main domain and your www subdomain redirect to the same place, I have an alert that my www subdomain is not secured in https, while it redirects to the main domain, itself redirected to https.

clarkwinkelmann

BlackSheep could you share the report url you are talking about ? I don't see any recent report matching your description.

Maybe you're talking about the HSTS flag being red ? You should serve the HSTS header along with a redirect when redirecting away from an HTTPS page, this will secure the domain even if it is different than your canonical domain.

I see multiple reports of website having messy redirects. Based on my knowledge the most secure way of redirecting is the following:

If the url is http, redirect to same page on https and apply HSTS header
Only then, if the url is using wrong domain, redirect to same page/homepage on canonical domain (and HTTPS)

Redirecting to another domain right away when on HTTP prevents using HSTS and therefore typing the same address or following the same link again in the future might expose the user to MITM.

Redirecting to an HTTP page from an HTTPS page is also very bad practice, in particular if it's on a different domain where the HSTS header is likely not yet applied.

Sanguine

clarkwinkelmann If the url is http, redirect to same page on https and apply HSTS header

...assuming you have a valid cert for this domain in the first place. Otherwise, wouldn’t it be better to just redirect to https://canonicaldomain ?

BlackSheep

@clarkwinkelmann Sorry, I think I've been talking nonsense, or misspoke. And since an image speaks 100 times more than a line of text:

And the nginx configuration that pauses problem: redirection of the www on the main domain :

server {
  listen 80;
  server_name www.speedrun.cafe;

  location / {
     proxy_set_header Host www.speedrun.cafe;
     proxy_redirect https://speedrun.cafe/ https://www.speedrun.cafe/;
  }
}

clarkwinkelmann

BlackSheep I'm not very familiar with nginx but this looks like a transparent reverse proxy configuration, not an HTTP redirect response. This would result in the origin server thinking it's always hit via the correct url, but in fact allowing both domains to work.

XavierLoo

I get this report after running the test on my own Flarum site haha. Now I doubt if I were installing a genuine Flarum install. ?

Extensions

`Could not detect any loaded module/extension. Is this really a Flarum install ?`

p.s. I get this report too BlackSheep but not really understand what's going wrong..

Btw, thanks @clarkwinkelmann for making this awesome tool ?

clarkwinkelmann

Sanguine if you're able to deploy HTTPS for any domain you resolve it's a lot safer to first redirect to HTTPS.

Though if you're not using HSTS or 301 redirects it has little benefit. But everybody should be adding HSTS headers now, it doesn't require any particular effort. And if you use HSTS preloading, which is a very good thing, you'll need to secure every single subdomain you serve anyway.

Sanguine

clarkwinkelmann t's a lot safer to first redirect to HTTPS

What is the attack vector here? As opposed to directly redirecting to the canonical domain https.

clarkwinkelmann

Sanguine

some scenarios:

Website canonical url is https://example.com/. Let's suppose all HTTPS-enabled routes on example.com and www.example.com answer with an HSTS header with a maxAge of 6 months

User visits http://www.example.com/ and is redirected to https://example.com/ with a 302 redirect
- User can be subject to MITM attack on first request
- If the user visits http://www.example.com/ a second time, still vulnerable to MITM
User visits http://www.example.com/ and is redirected to https://example.com/ with a 301 redirect
- User can be subject to MITM attack on first request
- If the user visits http://www.example.com/ a second time, might or might not be vulnerable to MITM depending how long the 301 redirect is cached by the browser
- If the user visits a different url on the non-canonical domain, for example http://www.example.com/test, it is like starting over again and will expose to MITM again (even if the 301 redirect of the other url was cached by the browser)
User visits http://www.example.com/ and is redirected to https://www.example.com/ with a 301 or 302 redirect (and then to https://example.com/)
- User can be subject to MITM attack on first request
- If the user visits http://www.example.com/ a second time within 6 months with the same browser, no MITM possible because the browser won't try accessing the url over HTTP
- If the user visits a different url on the non-canonical domain within 6 months, for example http://www.example.com/test, the browser will immediately use HTTPS for that url and won't attempt an HTTP connection

Using HSTS preload of course makes every single one of these scenarios secure against MITM if the user is using a browser with a preload list including your website.

If the user is using a browser that doesn't support HSTS or the website isn't serving HSTS headers then scenario 3 will be identical to scenario 2. But support is pretty good https://caniuse.com/#feat=stricttransportsecurity

EDIT: If you're redirecting from www to apex and use the includeSubdomains HSTS setting I'm actually not sure whether my point still holds. You can redirect directly to apex over HTTPS and all subdomains will be covered by HSTS. The point still holds true if you're redirecting to a completely different domain or a domain that's at a lower DNS level (like apex to www)

EDIT2: by the way MITM does not only mean a proper attack to steal user data or impersonate the website. It could also be an SSL downgrade to inject ads or mine cryptocurrency.