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.

CommentFileSizeAuthor
#4 1914932-4.patch407 bytesswentel

Comments

chx’s picture

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

gdd
he/him
Primary language English
Location Portland, OR
commented
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

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

swentel commented
Status: Active » Needs review
StatusFileSize
new 1914932-4.patch407 bytes

There you go

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented
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.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented
Issue summary: View changes

Updated issue summary.

chx’s picture

chx commented
Status: Needs review » Reviewed & tested by the community

Purr-fect.

hass’s picture

hass commented

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

hass commented
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

swentel commented
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

chx commented

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

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

hass’s picture

hass commented

"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

(not verified) commented
Issue summary: View changes

Updated issue summary.