Is Flarum Secure?

JimP

The issue

I post this question as I just had to rebuild by website by copying across all files from an archive including the flarum folder. When I tested the site online I found a whole bunch of php errors, presumably because flarum itself was not running. But included in those error lines was text of my username and passwords used on flarum - in clear text.

Obviously the flarum folder was quickly removed again. But it begs the question as to whether those php files could have been accessed by others, even if Flarum is running.

luceos

JimP what exactly did you see and where? I don't think this ever happened before, unless your server wasn't installed with php; this would then show the raw php and thus also the raw config.php. Not something that is supposed to happen.

Please do clarify.

Gorm

JimP my Flarum accessible in the wild near 1 year. Did you really think that some kind of hackers called kiddies didnt try to destroy it? 🙂 So, I am absolutely sure, there is no any actual public security advisories with any critical status. 0day - of course maybe 🙂 But I didnt meet it. I meet very fast response and fixes for any detected security related problems (XSS, unlimited avatar uploads etc.).

Your problem looks like misconfigured PHP+paths or Web-server directive/rules. Maybe short_tag, maybe rewrite related. Maybe include errors (check your paths). In any case, error reporting must be disabled in production environment and debug must be turned off. Seems your PHP is just didnt work. It is not security related. Its just misconfiguration.

clarkwinkelmann

If you use the public folder installation method (the recommended and default) then all sensitive files and all executable files except index.php will be outside the webroot, ensuring that they will never be returned or directly executed by the webserver even if the PHP or rewrite modules get disabled or removed.

The legacy method of putting all files in the webroot and protecting them with rewrite rules is supported by Flarum (as described under "customizing paths" in the documentation) but is inherently less secure due to depending on other modules being enabled, and this is probably what happened to you here.

Even then, the Flarum config file should only contain database credentials, which you should configure to only work when accessed from localhost, so even if an actor steals your database credentials, they cannot be used without also having shell access to the server.

The other secrets like the SMTP password are stored in the database and Flarum restricts their access only to admins. I remember discussing making password-like settings readonly in the admin panel to prevent them being stolen from a compromised admin account, but I don't believe we have implemented this yet. Some credential settings benefit from being readable for ease of troubleshooting.

As for how secure Flarum's code is, nothing is ever 100% secure, but I think our track record so far is pretty good 🙂

JimP

The issue occurred when trying to re-install a website that had to be moved to a new server. I simply copied the archived Flarum folder into the new website in the same location as before. But I had not yet re-installed the Flarum application files. So in opening the website page there were displayed a series of php errors, including username and password details.

So yes, some configuration errors. But still have concerns over the information displayed as a result of that error. When I can get my Bluehost hosting to work properly again I will try to recreate the error to give more data.

luceos

JimP just to be clear Jim. Flarum does not show your username and password. We even have logic in place to prevent your database credentials from showing. But in the end, as said before, if your hosting environment is misconfigured or the files were uploaded in the wrong spot, things can still go wrong.

JimP

When installed - several years ago - I used the Flarum tools to install everything - I don't remember the details but I don't recall it being a manual process. I certainly didn't have to put individual php files in place.

When I now look at the archive, inside public-html/flarum is a file config.php. That file includes the username and password for the flarum system, in clear text.

When the flarum folder was re-loaded into the live public-html folder, and the page calling the embedded forum was clicked, it listed a series of php errors, including the details of the config.php file showing the username and password. Presumably there are some further steps I need to get Flarum working again, but at this stage in the process it does look like the username and password are in the public domain.

This seems to be consistent with the statements by clarkwinkelman and I trust that he is correct in that those user details cannot be used outside the local environment. But it was a little alarming to see them popup on the page in an error message.

php is installed on these servers, so now I need to understand why it was not kicking in after re-loading the flarum folder.

luceos

JimP config.php is supposed to be outside of the public html, that's also why Flarum ships with a public folder, similar to what Laravel does, to show that only that folder should be public. But yes, if PHP is not enabled for this website/docroot the contents of the config.php will show up in cleartext if you host that file in the public space - something we recommend against.

I just want to be clear that this is not a Flarum issue, it is a user issue for two reasons: a) the hosting environment is not running php and b) recommendations to keep the config.php safe by hosting it outside of the public folders were not followed.

fakruzaruret

Can we say Flarum pass owasp top ten api criterias for security?

https://owasp.org/API-Security/editions/2023/en/0x11-t10/

JimP

I would say that the "recommendations to keep the config.php safe" are not really written as recommendations, rather as observations in the Installation section, perhaps they could be a little stronger. It says you can install in public, but does not explicitly recommend against it.

It does look like the original installation was in the public folder so obviously the impact of those words did not sink in at the time of installation.