Problem/Motivation

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.

Proposed resolution

Review the relevant rules in .htaccess and web.config and alter them so that they match, as appropriate.

Remaining tasks

* Review the rules, and decide what changes need to be made to each.
* Make those changes.
* Check whether any tests need to be updated.

User interface changes

None.

API changes

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.

Data model changes

None.

Comments

mcdruid created an issue. See original summary.

mcdruid’s picture

mcdruid commented
Parent issue: #2948579: Block web.config in .htaccess (and vice-versa) »
ayesh’s picture

ayesh commented
Assigned: Unassigned » ayesh
ayesh’s picture

ayesh commented

Hi @mcdruid and everyone,
I did some research round the web.config and .htaccess regular expressions, and you are right there are things that we should align well, plus there is a big room for improvement.

https://regex101.com/r/WZAIsO/1

1. Performance
This regex has 1789 steps. This is too much considering we only need to match the file extension and certain directories. Because we will need to release an .htaccess update, I think it's better if we optimize this s well.

2. Add-only modifications over time
The regular expressions long and somewhat difficult to maintain. In addition, we have one more rule that blocks all files and directories starting with a dot. This longer regex is long and hard to wrap head around. The regex is so long you can write and publish small npm package before you finish reading it. I suggest that we remove some redundant rules.

ayesh’s picture

ayesh commented
Related issues: +#3017095: Clean up .htaccess and web.config file protection

I created another issue because I didn't want to hijack this issue, which I believe the main focus is reconciling .htaccess and web.config. However, I also believe a wider clean up for these files are also in order.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mastap’s picture

mastap commented

I am wondering why we don't reverse this logic, and only list the extensions and file pattern that we want to serve, excluding all the others from being served.
I feel this would secure even more the environment.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.