- 🇨🇦Canada mastap
I am wondering why we don not reverse this logic and only list the extensions and file pattern that we want to serve, excluding all the others.
I feel this would secure even more the environment.
Follow-up based on #2948579-15: Block web.config in .htaccess (and vice-versa) →
The .htaccess and web.config files provided with core both contain rules to block access to source / config file which should not be viewable through the webserver e.g.
# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|install|make|module|profile|po|sh|.*sql|theme|twig|tpl(\.php)?|xtmpl|yml)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock))$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig|\.save)$">
However, as @longwave pointed out in the linked issue, the rules seem to have got out of sync (i.e. they don't match exactly) across the two files:
I did also notice that the regexes differ elsewhere in a few places - web.config blocks code-style.pl (not sure why) and what looks like SVN repository files, but not .make files - we should probably open another issue to unify this properly. Both files also block .xtmpl files, which are surely long obsolete.
Review the relevant rules in .htaccess and web.config and alter them so that they match, as appropriate.
* Review the rules, and decide what changes need to be made to each.
* Make those changes.
* Check whether any tests need to be updated.
None.
None... I think; although it's possible that changing these files could change the behaviour of existing sites... so that'd need to be considered.
None.
Active
10.1 ✨
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I am wondering why we don not reverse this logic and only list the extensions and file pattern that we want to serve, excluding all the others.
I feel this would secure even more the environment.