Problem/Motivation

We provide a .htaccess file in the config active directory, but not the staging directory

Proposed resolution

Dynamically add: .htaccess to config staging

Much like .htaccess is added to config active now.

Remaining tasks

Actually code it.

User interface changes

None.

API changes

None.

Original report by hass

// Text of original report here.
(for legacy issues whose initial post was not the issue summary)

As an outcome of #1914018: hook_requirements() for un-protected configuration directories I found that web.config is not protecting the folders sites\default\files\config_*.

We may also need to review the match filters of .htaccess in the root folder of Drupal if we need to do something there or not.

Files: 
CommentFileSizeAuthor
#4 1914932-4.patch407 bytesswentel
PASSED: [[SimpleTest]]: [MySQL] 50,345 pass(es). View

Comments

chx’s picture

Title: Protect .yml files and config_* directories from prying eyes » web.config does not protect config directories
Component: file system » configuration system
heyrocker’s picture

Issue tags: +Configuration system

We should not be globally blocking .yml from the root, because there are lots of uses for it in other areas of core and contrib that are unrelated to CMI and may legitimately need to be left available. There is already one in the root of the active directory which is Deny from all so that is covered. We should however add one for the staging directory, that is a legitimate task.

chx’s picture

Title: web.config does not protect config directories » Config directories need more protection (htaccess, web.config)
swentel’s picture

Status: Active » Needs review
FileSize
407 bytes
PASSED: [[SimpleTest]]: [MySQL] 50,345 pass(es). View

There you go

heyrocker’s picture

Title: Config directories need more protection (htaccess, web.config) » Config staging directory needs a .htaccess file

There is actually already an issue for the web.config at #1543392: Add a web.config to the several directories similar to the .htaccess file. So lets just take care of the staging .htaccess in this issue and leave web.config in the other one.

heyrocker’s picture

Issue summary: View changes

Updated issue summary.

chx’s picture

Status: Needs review » Reviewed & tested by the community

Purr-fect.

hass’s picture

This issue was opened because everyone is able to enter the public config url to the config_* folder and can read all .yml files and there is no .htaccess protection at all.

This is not a feature. I'm not sure how #4 should protect against this type of attacks. I will switch #1543392: Add a web.config to the several directories similar to the .htaccess file into a critical bug.

hass’s picture

Title: Config staging directory needs a .htaccess file » web.config does not protect config directories
Status: Reviewed & tested by the community » Needs work

Please don't highjack my case.

swentel’s picture

Title: web.config does not protect config directories » Config staging directory needs a .htaccess file
Status: Needs work » Reviewed & tested by the community

You now just hijacked it yourself, keep it like it is, this works perfect with .htaccess, web.configs can be solved in the other one.

chx’s picture

Per #5.

hass, we told you several times that "everyone is able to enter the public config url to the config_*" is false because you can't know the *. It's saying "anyone can create the session cookie for uid 1". Right. In fact, they are the same strength hash wise. And, similarly any code has access to the session id and could reveal it much like it could print the path to the active config dir. Do not get overexcited over this and stop opening uncounted numbers of criticals over it. Yes, we get the concerns, they are being patched, calm down.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

hass’s picture

"everyone is able to enter the public config url to the config_*" is false because you can't know the *. It's saying "anyone can create the session cookie for uid 1". Right. In fact, they are the same strength hash wise. And, similarly any code has access to the session id and could reveal it much like it could print the path to the active config dir.

  • I said several times that this cannot compared to a session. A session is active for a relatively short time and will never come back again. It is destroyed after I click logout or this should at least be the case (unverified).
  • Compared to this, the config directory does not change after let say 1 hour (session timeout). It will have the same hash for ages. That I'm able to change this doesn't make it better. Once it has been guessed or found it can be used for ages without getting timed out.
  • It's also localed in a public directory and not protected by web.config. If it would be outside of the webroot it cannot accessed by a browser. This is a lot saver as I need root access to the machine or need to be able to place php code on the system to compromise it, not just enter a url.

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Updated issue summary.