MigrateToFlarum Lab, the health scanner for Flarum

clarkwinkelmann

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.

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 ?

Sanguine

clarkwinkelmann Thanks for elaborating! You made it very clear.

One issue with freeflarum.com is that the services has a wildcard DNS entry (*.freeflarum.com) which makes www.xxx.freeflarum.com resolve, but the wildcard certificate doesn't catch that (as * in SSL certs don't match dots). So FF users now get a warning, which is probably confusing, as nobody uses the www prefix. Any ideas?

Sanguine

I added this to my global Nginx config, to redirect http://www.sub.ff to https://sub.ff:

server {
        listen 80;
        server_name ~^www\.(?<tag>.+?)\.freeflarum\.com$;
        return 301 https://$tag.freeflarum.com$request_uri;
}

But I still get a grade B on your scanner, because there is no valid SSL certificate at https://www.test.freeflarum.com. Please advice ?

clarkwinkelmann

Sanguine ooops never realized DNS wildcards resolved any number of subdomains below ?

That issue reminds me of StackExchange and their many meta subdomains

I have no idea how you could reasonably fix this ? I could make my rating a bit more tolerant but I'm not sure it's worth it. It will still show a warning if somebody does type that url and that's not good.

Some things that come to mind: generate certificates on the fly for these subdomains (I've heard it's possible) or create certificates for every one of your subdomains and use SNI to serve the correct one, but it's a lot more stuff to monitor...

Or maybe you could use a DNS service with pseudo-wildcards that only resolve the third-level domain.

Sanguine

clarkwinkelmann I could make my rating a bit more tolerant but I'm not sure it's worth it

May I humbly suggest to not check for the www prefix in case the domain is a subdomain of a domain + public suffix already? In the case of discuss.domain.tld or forum.domain.tld, nobody uses www.discuss.domain.tld and www.forum.domain.tld so there is no real risk if they don't serve SSL. In the odd situation that somebody ends up there by mistake (manual fiddling?), the browser will prevent accessing the site anyway.

Or, alternatively, drop the check for https on the "www" version in case the www.subdomain:80 redirects to a https URL ?

To fix it on my end, I would set up individual DNS record generation, but I would only do it to satisfy your check, not because I feel there's an insecure situation currently. So that feels like a wrong solution.

clarkwinkelmann

Sanguine I really don't know...

My thoughts are as follow: the forum is correctly configured if a visitor can't see any security error at any point.

A fourth-level www domain not resolving is not a concrete error and the browser simply will tell the visitor the address is incorrect. No harm done.

However if the domain does resolve it becomes something the user might type and should not show a security warning.

If the domain uses HSTS with includeSubdomains and/or preload and types a fourth-level www subdomain it will automatically load the HTTPS version of that page and cause security warnings, so redirect when http is not enough.

What about not answering on port 443 for that subdomain ? That would trigger a proper not found message in the browser and that's something I could say is acceptable in my rating. But if it's the same IP answering all urls you have to wait for the Server Name Indication and this will probably be too late to make it look like port 443 is closed.

Damn that's not easy...

Sanguine

clarkwinkelmann If the domain uses HSTS with includeSubdomains and/or preload and types a fourth-level www subdomain it will automatically load the HTTPS version of that page and cause security warnings, so redirect when http is not enough.

But FF does not (anymore ?) uses HSTS w/ IncludeSubdomains, so in that case, a normal http > https(canonical) redirect would be ok, right?

clarkwinkelmann correctly configured if a visitor can't see any security error at any point

One could say this is a subjective norm, as there are always things that could trigger an error. Eg. (for sites that correctly implement the DNS RFC) localhost.domain.tld or smtp.domain.tld. But, no sane person types in mail.flarum.org (gives 404). So you limit the set of arbitrary prefixes to the one commonly used: "www". But I'd argue that it is also common practice to not use the www prefix in case of a subdomain. Potato, potatoe ?

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

XavierLoo you could have given me a link to the report or the website url as it's not showing up in the homepage of the lab ? (if there's an error it's not shown on the homepage) I guess you're talking about http://ct.pharosic.com/ ?

you've got some strange cryptographic-based javascript redirect response that's interfering with my crawler. My script sees the redirect script (http://ct.pharosic.com/) instead of your Flarum (http://ct.pharosic.com/?i=1).

The crawler only follows HTTP redirects, not javascript-based ones. And currently I don't accept forum homepage urls that use query strings (they are removed) so there's no way to scan your website in its current form ?

XavierLoo

clarkwinkelmann yup, that's my forum. Actually I don't know why there is a redirect script.. I might need to consult my server service provider (currently using free hosting)

Updated:

Answer from the service provider

I understand these suffixes (http://yourwebsite.com/?=1) look ugly, however, they are a necessary part of our system to protect websites against malicious bots. These suffixes are completely harmless though, they won't prevent legitimate visitors and search engine spiders from accessing your website.

I think that's what blocking your crawler's way ?

PranavJadhav

I found this site in showcase its pretty impressive, https://halfminer.de, but im not able to lookup the extensions being used (Could not detect any loaded module/extension. Is this really a Flarum install ?), how can i do so? and also how is he hiding those

clarkwinkelmann

PranavJadhav that's because https://halfminer.de/ isn't a Flarum page. https://halfminer.de/forum/ is.

That second url scans just fine ? https://lab.migratetoflarum.com/scans/11dca935-8cb5-48f9-a908-f41cf5ec643a

0E800

@clarkwinkelmann
May you please help me understand what I need to do in order to get the far opposite result of:

Multiple urls
This Flarum is accepting connections via multiple urls which will result in an invalid config.url value being used for some of them. This will also impact your search engine ranking by creating duplicate content. Setup redirects so only the url defined in your config.php (https://keys-daggers.org) can be used to access the forum to fix it.

Vendor folder
Your vendor folder is currently being served by your webserver. This could expose untrusted scripts to the world and compromise your security. Use a rewrite rule to prevent your webserver from serving this folder.

I am mostly concerned about the Vendor folder.

I could not find a post that included the proper permissions for the flarum folders with regards to what shouldn't be publicly available. The posts I found were mostly for users that had issues with permissions trying to install.

Any reply would be greatly appreciated, and thank you for providing this most excellent service. ?tips.

luceos

0E800 to protect your vendor folder you'll have to properly set up your nginx configuration (assuming nginx because the default .htaccess already covers this). You'll have to do something for Nginx like we did in apache:

https://github.com/flarum/flarum/blob/v0.1.0-beta.7/.htaccess#L26

In fact the nginx config in the docs also cover the vendor protection:

location ~* ^/(composer\.(json|lock)|config\.php|flarum|storage|vendor) {
        deny all;
        return 404;
    }

0E800

@luceos

Thank you for the pro-tip.

I had installed my instance using @webeindustry 's install script:
https://github.com/webeindustry/flarumvpsinstallscript/blob/master/script

Which used:

    location /flarum {
        deny all;
        return 404;
    }

I replaced that with your recommendation :

location ~* ^/(composer\.(json|lock)|config\.php|flarum|storage|vendor) {
        deny all;
        return 404;
    }

Now I am good to go.

Thank you sir.

robetus

Lots of false positives. Said my vendor and storage folders were accessible but they're not. Tried it myself. I have the following in my htaccess file:

  RewriteRule ^vendor/(.*)?$ / [F,L]
  RewriteRule ^storage/(.*)?$ / [F,L]
  RewriteRule ^config.php$ / [F,L]
  RewriteRule /\.git / [F,L]
  RewriteRule ^composer\.(lock|json)$ / [F,L]

clarkwinkelmann

robetus what's your website ? You can send it to me via Discord PM if you don't want to list your url publicly.

The folders are considered "exposed" if the status code returned by some well-known files in these folders is 200. The apache rewrite rule F should return a 403 status code and my scanner should be fine with it.

clarkwinkelmann

Ratings just got better (and more fair).

Now the reason behind the rating are written beside it. And I'm no longer punishing domains with errors on their www subdomain if it's not a first-level domain (@Sanguine this will make you happy I guess)

Also the "+" is now only granted if you have a HSTS of 6 months or more.

And I introduced a "-" (minus) that is currently only given if your forum is in debug mode (to my knowledge having debug mode on in Flarum usually doesn't expose any sensitive data or setting, if it were the case I'd cap the rating to D like the other security issues)

Happy scanning !

Sanguine

Hurray! Thanks for listening to the crowd. You would make a great politician (perhaps you are one?).

Minor nitpick: apparently you can score A+ whilst lacking a CSP header altogether? https://lab.migratetoflarum.com/scans/40cd240b-5b9b-4d98-9236-26b0a649fdd8

clarkwinkelmann

Sanguine apparently you can score A+ whilst lacking a CSP header altogether

CSP being so complicated with Flarum right now I'm not taking it into account for the score.

Because having CSP with eval, inline-scripts and inline-style really is like having no CSP at all ?

« Previous Page Next Page »