MigrateToFlarum Lab, the health scanner for Flarum

clarkwinkelmann

I have changed the Lab homepage so that only websites which rate C or higher are visible. This prevents D rating from being advertised and also hides failed reports from previously valid Flarum installs.

Kylo

Is being able to show a version of an extension (or providing a list of extensions) good thing to have? Some extensions certainly may have some security vulnerabilities and we're just welcoming others by providing that we're on that version (or using that extension) with a simple request/response action. What do you think?

clarkwinkelmann

Kylo actually it was kind of the point of implementing that. To be able to warn against outdated or vulnerable extensions.

I have never implemented the vulnerability part for extensions because we've had so few instances and nothing serious yet I believe. If a serious vulnerability is found in an extension I'll give priority to get this feature implemented.

Just like I now do for configuration issues, those reports would get a D rate and be hidden from the homepage.

I don't think offering this feature on the lab causes any more significant risk. Doing what I do is very easy. Any bad actor could easily create a tool that does the same but scans many more forums much more quickly.

In my opinion offering those features on the lab empowers the forum owner because those are checks they might not be able to easily do by hand. Even if someone else scans someone's forum I'd hope they will report their findings to the owner.

If I see vulnerable reports passing by and know who owns the forum, I usually try to ping them if I see the issue not being fixed after the scan.

clarkwinkelmann

I have updated all javascript and PHP dependencies of the Lab and updated the frontend to Mithril 2.0 (from 1.1).

I ~~think I~~ have tested every feature, but let me know if something is broken 😇

nether494

@clarkwinkelmann Hi,

How to fix this please:

Insecure public folder
your vendor folder is publicly reachable
your storage folder is publicly reachable
your composer.json and/or composer.lock files are publicly readable
Not found. HSTS headers prevent traffic from being downgraded to HTTP

Do you have documentation? I don't understand how to fix these problems

clarkwinkelmann

nether494 make sure you change your DocumentRoot of follow https://flarum.org/docs/install.html#customizing-paths to remove the public folder.

The htaccess includes the required rules to hide those files with mod_rewrite which you can uncomment. That's explained in the "customizing paths" instructions.

nether494

clarkwinkelmann Thanks man, now I have

Multiple urls

I have a .nginx.conf and this is my last problem 😃

How to fix this please

clarkwinkelmann

nether494 if you search for "nginx redirect www" or something similar you should find examples on how you could fix it in the nginx config.

Or you can use the Canonical Url extension.

nether494

clarkwinkelmann Last rating -> A+ ! Big thanks to you my friend, nice work! 🙂

clarkwinkelmann

New feature!

Now the lab gives you a detailed look at what's taking space in your javascript files.

"Flarum Core" and "Flarum TextFormatter" are the base components of Flarum, so you can't do much about them. Then you'll see each extension sorted from the bigger impact.

We can notice that there's rarely one extension having a huge impact (except Password Strength and EmojioneArea at 830 and 650 kB respectively). But it quickly adds up when you have many extensions.

Extensions with a triangle are those that were not compiled for production before being published. If the author re-compiles the extension for production it will take less space. @askvortsov is already on the case for his extensions by the way.

The lab is not going to offer any recommendation regarding assets size. It's up to you to decide what you do with this information.

I plan to also add details about the language and CSS files in a future update.

Littlegolden

clarkwinkelmann Is this due to geographic location?

matteocontrini

clarkwinkelmann Now the lab gives you a detailed look at what's taking space in your javascript files.

It's your fault! 😂😂

clarkwinkelmann Flarum versions 10 to 12 are shown as "beta 10/11/12" because there's no way to tell them apart from the homepage source code. A more advanced detection is planned, but I can't say when it will be available.

For future version, wouldn't it be useful if Flarum itself exposed the version? It's not a particularly sensitive information IMO, pretty much every forum platform out there exposes the version in the footer or in the source code.

clarkwinkelmann

Littlegolden yes it could be. Or maybe there was a sudden spike in traffic on one side or another.

If it happens every single time it's a bit concerning. If the javascript takes more than 20 seconds to be downloaded.

The lab is hosted on DigitalOcean in Germany.

Gatsu

clarkwinkelmann hi,
can you help me for fix it?

https://ibb.co/DwtHQCz

Littlegolden

clarkwinkelmann If it happens every single time it's a bit concerning.

Yeah... it happens every single time... My server is in Beijing.

Gatsu

Hi @clarkwinkelmann
do you sugget to activate Opportunistic Encryption on cloudflare?

Opportunistic Encryption allows browsers to benefit from the improved performance of HTTP/2 by letting them know that your site is available over an encrypted connection. Browsers will continue to show “http” in the address bar, not “https”.

askvortsov

Gatsu I'm a bit confused why you would want to make https optional at all: in 2020, every site should be using encryption. I'm assuming this is moreso a leftover feature, and not really something you want for the modern age.

clarkwinkelmann

Gatsu I suggest using the Full(strict) + Always use HTTPS + HSTS with preload options.

I see Opportunistic Encryption is enabled by default, so I wouldn't bother touching that setting. As I understand it has no effect if you force HTTPS anyway.

tankerkiller125

matteocontrini For future version, wouldn't it be useful if Flarum itself exposed the version? It's not a particularly sensitive information IMO, pretty much every forum platform out there exposes the version in the footer or in the source code.

While many forums do share the version someplace it's generally a bad idea. It's not going to cause massive amounts of abuse no. But lets say that we fix a major security issue in say 1.1.5 and the versions affected are everything back to version 1.0.2 (random version numbers) then in theory attackers could create an exploit and then do a massive scan of all forums that are within that range and attack them all quickly, effectively and with extreme precision.

By not including the version number in the code or display it means that the attacker has to try attacking ALL Flarum installs, regardless of whether it's updates or not. It probably wouldn't slow them down all that much, but it might be discouraging to them to see hundreds of sites return with nothing promising and they might just stop trying.

matteocontrini

tankerkiller125 yeah but the version is actually still detectable even without having the version exposed, it's just a matter of finding a specific line of code that is present in a version and not in the previous (or next?).

It could also be an option, for those that don't want to expose the version.

SezginYILDIRIM

Trying to scan my site, it gets stuck in part 2.

https://lab.migratetoflarum.com/scans/8bd2eabf-8683-40c1-bfd3-3438f876d81a

clarkwinkelmann

SezginYILDIRIM there is an encoding problem on your homepage, most likely inside of the preloaded discussion data. It's not valid UTF-8.

I have improved error handling for invalid encoding, now it should at least provide an error message. Previously the database requests would fail because it was trying to insert the data in MySQL. This left the scan in an unfinished state.

« Previous Page Next Page »