• DevInternals

  • Sensetive Path Blocking - A Valid Security Initiative?

Hello Everyone,
It's going to be abit long this time and I hope you guys would find it meaningful.

I consistently execute security assessments to improve the overall security posture from time to time. Most of the assessments are self-check assessments and pentests. Somehow - this time, i decided to utilise external reputable sources which was two reputable cyber security risk assessment platforms via their provided online scanners and somehow found that the cyber security score which consists of best practices in place hits a satisfactory level [901 out of 950 and A out of A+] and based on my checking both of this platforms consistently update their threat inteligence as well as security checkpoints regularly which means most of the new type of threats and attacks as well as CWEs are included and measured as well.
*The nature of tests is over the Best Security Practices as this scanners doesn't include outer layer blockage such as WAF Blockage into accountability. So, the WAF was temporarily bypassed for them to scan and to provide an accurate result over the practices.

This has been a practice where all traditional security practices are fulfilled and then blockage through waf is done as an additional layer so that in any event anything goes wrong at the core aspect such as maybe accidentally indexed something that shouldn't be, it would still remain inaccessible as the WAF is blocking access to the source in addition.

Well, i conduct all as per what i know and i am not a security expert nor a expert but then i conduct based on my own logical & critical thinking + Analysis conducted = verified via sources on the internet and sometimes, i seek for open opinions from subject matter or community experts as how as i usually start a discussion here and also as this at below.

No System is 100% Secure
Being alligned to the self-initiative to consistently and persistently improve the security level and posture i came to a point where i was thinking:

1] Do restricting accesss to this certain sensetive paths as below related to flarum script is a valid security strengthening move?

*The Blockage would be done at Cloudflare WAF Custom Rule area or in other words i prefer to call it as at the F.L.O.D [First Layer of Defense] - due to its nature of blocking before it even reach or fetch from the origin. Upon the implementation of this block, whenever someone tries to access those at above paths, they would be returned with a block page or 403/forbidden error code.

I had manually inspected all this paths and it returns with 403/forbidden at my origin which is good as i expect it to be restricted at the origin as per how it should, but, somehow looking forward to restrict it via the F.L.O.D WAF as well.

Why such move?
Let's make the debug path as an example. In any event i am encountering an issue with my script i would be enabling debug mode which consequently would provide informations through the path. I wanna block those information from being publicly accessible by others therefore restricting it at the F.L.OD WAF would give me an advantage of which only i would be able to view those informations as my ASN+IP is the only one whitelisted to access it whereas anyone else would experience a block page or 403/forbidden error code.

Security is essential but the use-case and functionality of the system is even more important.
2] So, what would be impact rate of executing as shared above, Any trade-off with the functionality such as any element of my flarum could probably break or slow down?

3) It comes to threat defense model somehow, but then, how efficient would probably this move be?

I am entirely open to criticism, constructive feedbacks as well as ideas.

Appreciate the feedback from all respected members and the executors [builders] of this amazing flarum.

Thanks in advance.

It certainly won't hurt, but it might be unnecessary.

If you host Flarum using the public folder and a document root set to that public folder, the folders outside of public will never be served by the webserver.

If you don't use a public folder and use Apache rewrites to block access to those files, there is a slight risk the files might be exposed if during a server upgrade the rewrite module somehow gets removed. In that case a secondary layer of defence doesn't hurt, but really the public folder solution is preferable.

Blocking those paths in the proxy creates an additional step that could lead a an increased latency and resource usage, but we're talking about incredibly small amounts that are unlikely to affect any small to medium community. Even more so if you are not hosting the proxy yourself but relying on an optimized service like Cloudflare.

Some remarks on your rules: you have 2 different rules for storage folder. You should block the entire folder, so the second rule for one specific file is unnecessary. The rules for public make no sense, because there shouldn't be a public folder in your Flarum folder if you use the "customized paths" instructions. If there is a public folder visible in any URL in your browser, Flarum is not installed correctly.

And just a closing note that doesn't impact security, but if you want one of your Flarum pages to be named the same way as a sensitive folder (for instance there's an extension creating a /composer page) blocking at the proxy level will make it impossible to create such a page.

    clarkwinkelmann
    This is the current posture in my directory :
    [I've Removed it for Privacy]
    Files are set to 644 whereas folders are at 755. The public folder is empty, it seems like everything is outside of the public folder. This is probably because when i first installed flarum, it automatically inserted /public to my url.

        KARAM_SIDHU what's in the public folder? You can probably delete it entirely.

        There are a few other files in your screenshot that were not created by Flarum, and were probably put there by your hosting. Is error_log the actual PHP error log? It would be strange for a hosting to put that file under the webroot where anyone can grab it 🤔 I'd also recommend deleting the phpinfo.php file when you're done with it.

            clarkwinkelmann the public folder is empty. Shall i proceed to delete it directly? Do you mind to assist to list the actual directory consists of folders and files that in actual belongs to flarum so that i can cross check and verify against what i have on my host?

            In regards to placing it in the webroot, i've tried accessing some files out of those, they're not publicly accessible and there is an according rewrite in .htaccess.

                5 days later

                clarkwinkelmann Based on my checking, i compared the fresh copy with the one that i am running, I found the difference of :
                1 folder = public
                3 files = .user.ini error_log phpinfo.php

                The public folder and phpinfo.php file had been deleted as advised, whereas the .user.ini file is as per my request to the host to specifically increase the memory limit and max execution time for my flarum [/forum directory] as previously there were timeout issues with my script when installing extensions via extension manager. The error_log file seems belong to my server-end environment which captures errors on the execution of activity via composer and it only contain previous logs which now has been deleted

                The folders [storage and vendor] and files that were supposed to be placed outside of the public accessible area as encouraged for best security practices had been checked each by each by directly attempting to access it to ensure it wasn't revealing any sensetive information by mistake all the while and fortunately all the attempts returned as restricted [403 - Forbidden] at origin. However, to further enhance it, the access to all those paths had been also restricted via F.L.O.D [In my case - Cloudflare WAF] with comprehensive block for folders and specific block for the files as a double layer in case if any unrealised circumstance occurs at the origin htaccess level, the accessibility would remain restricted.