0E800 ?

Sorry everybody who scanned their forums today, there was an issue with the last update which rendered an empty list of extensions ? A fix is being deployed as I speak (type ?).

    Just launched my first Flarum and am super excited about it! ( https://www.seekadventure.net ), feel free to join and discuss if you like ;-)

    Anywho saw your tool and am using it to clean up my site before I start sending it out to the masses. I could use some pointers on what some of the warnings mean. I figured out the HSTS and got that working, now I need CSP and vendor, storage and composer files help.

    Just looking to be pointed in the right direction!

      I used the best descriptions I could come up with for the various warnings, but I expect they can be greatly improved. Please let me know if you find a better wording.

      MikeJones What I could add is a link to the official documentation. The 3 "security" warnings should not happen with Apache because the included .htaccess prevents them. With nginx, the example config was recently fixed to prevent them as well. For any other webserver the official doc doesn't cover it and you need to find the needed rules to fix them. It's about blocking access to those files, because if anybody can access them by writing the filename in the url, then they could access private data or run untrusted scripts.

      Regarding CSP, it's an optional thing. If you scroll up this discussion you'll find links to other discussions here about CSP.

      Hope this helps ?

          clarkwinkelmann It's about blocking access to those files, because if anybody can access them by writing the filename in the url, then they could access private data or run untrusted scripts.

          Whats the best way to block access?

              MikeJones from the headers returned by your server, it seems you are running nginx.

              The following rule from the example documentation takes care of that. Make sure you're using it in your own configuration.

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

                New features coming to the lab !

                I'm now also analyzing extensions themselves. Developers don't have to do anything, new extensions and new versions are automatically fetched and added to the list (once per day for now). Right now only versions hosted on GitHub benefit from the full features.

                I've started work on a first feature which tracks translations coverage. The lab will display:

                • Whether the translation files are valid YAML (most format errors are generated by the Symfony Yaml library)
                • Which translations are part of an extension
                • Which extensions provide translations for other extensions
                • A rough idea of the current translation coverage in other languages (with English as the reference)

                The UI is not very user-friendly for now, I have plans to improve it.

                You'll see that duplicates for each version of a language pack that translates an extension are currently shown with their own line in the translations table... This will also be improved.

                Go to https://lab.migratetoflarum.com/extensions to browse extensions and their analysis.

                Let me know what you think ?

                  Ralkage glad it helps. As you can see from the screenshot it also identified multiple issues with Bazaar.

                  Like for example we've merged an it language file (probably without actually testing it) and it can't even be parsed by Symfony Yaml parser ?

                  Also sometimes the identation is not correct and you end up not translating the strings you expect. Happened with the german file for Bazaar as well. I want to try to implement a real coverage tool (not just based on the total number of strings, but actual strings) so these issues can be identified.

                  I'm also planning to add some kind of notification feature in the future so you could subscribe to website or extension scan warnings. This might be a paid feature so it supports the hosting for the lab.

                    I think I've just identified a big contributor to the mysterious timeouts that have been happening lately.

                    I was using regular GET requests for security checks. One of my easy targets is the log file of Flarum, which always has the same name and is very likely to exist.

                    The problem was that when people did expose their log files, it was often megabytes in size and downloading it caused the request to exceed its allowed time. It both impacted the security rating (a request error is considered good when testing for exposed files) and was a big contributor towards the total run time of the scan, causing the whole scan to time out in some cases.

                    I've now switched all security checks to using HEAD requests. I didn't need the file content anyway. This will also prevent me from accidentally storing entire sensitive log files and exposing them publicly via the lab API...

                    The fix is now deployed. As always let me know if your scans time out or behave in a strange manner, there's probably something I can fix ?

                      2 months later

                      Lab update !

                      There is now a hall of fame on the homepage, showing the 5 most recent "A" ratings. I wasn't sure if it made sense, but as a few "bad" reviews are staying in the "recent" tab for weeks this will lighten the homepage a bit ✨

                      Also I fixed the annoying fact that the lab didn't correctly handle a discussion/tag/profile url and was complaining about a wrong Flarum base url. Now if you paste an url that looks like a Flarum sub-page, the lab will do an extra check to see if you really installed Flarum in a subfolder named like that or if it is a Flarum sub-page, in which case the sub-path will be removed to scan the actual Flarum home page.

                      I'm totally doing this just to have a valid reason to bump the thread ?

                        jordanjay29 absolutely. You can check "Do not show the results on the homepage" before starting the scan. Only people knowing the scan ID (in the url) will be able to see the results.

                        There's currently no way to make a forum "unplottable". If somebody else scans your forum and don't check the box it will be listed. But of course you may contact me directly if you'd like something removed.

                        Normally failed scans (public not not) also don't show up but I think there's an issue with that right now.

                          a month later

                          Lab update !

                          I just added basic support for beta8 forums, so that the list of enabled extensions continues to work.

                          I still need to implement the extension version detection for beta8, but the good news is that after the refactoring and migration to webpack this will be a lot easier and I will be able to deprecate my horrible module-import-based detector ? Not that it concerns any of you, it's hidden deep in the codebase ?

                          Also the lab homepage now shows the Flarum version (of new scans, beta8 is shown as dev-master for now) and the number of enabled extensions (including core extensions)

                          Discuss still shows up as beta7 as it's running an older dev-master that doesn't include the changes to the extension API and webpack ?

                            jordanjay29 that doesn't really apply because discuss wasn't updated for quite a while now. ?

                              2 months later

                              The Lab now shows whether a forum is vulnerable to the recently disclosed security issue.

                              Time to update your forum folks ! Hopefully this will help you check your forum has been properly updated.

                              Your rating will be capped to D while the vulnerability is present.

                              A few notes:

                              • Unlike the beta 7.1 vulnerability and because this one is a read-only vulnerability, I'm actually able to exploit the vulnerability without any impact on the forum. I'm not storing any private information that could get downloaded as a result of the test.
                              • I don't think adding this feature to the lab increases any risk for unpatched forums. The vulnerability is so easy to exploit that any attacker can easily build a way faster tool than the Lab to check for vulnerable hosts anyway.
                              • If you have deleted the original administrator user, the Lab will not tell if you're vulnerable or not (because I only check for that user in my test)
                              2 months later