Add a web.config to the several directories similar to the .htaccess file

We should also add web.config files to the config staging and active directories (similar to the htaccess files we already have there.)

I'm sorry, but this is a security breach and not an improvement as noted in #1914018: hook_requirements() for un-protected configuration directories. Everyone who known the path to the public configuration directory is able to read / download the .yml files that may contain critical information to attack a system. Obfuscating a folder name with a hash does not protect the folders data.

My case #1914932: Config staging directory needs a .htaccess file has been highjacked. They pointed to this case here.

I was shocked, that config is located in a public folder. This is a design flaw out of the box as it is insecure. As long as there is discussion about design a patch makes no sense.

We have implemented this -- but we are having an issue. When someone uploads a file, the file gets uploaded fine, but image styles versions like thumbnails are not being created. We don't really see why this should be the case, because the initial upload words fine. It is the subsequent creation of other files that is not happening.

Just the presence of the web.config without any settings seems to cause the problem.

Any ideas?

> Just the presence of the web.config without any settings seems to cause the problem.

Is IIS is unable to read the web.config file it will produce an error on accessing files in the files directory.

I have implemented the following web.config file in my files folder and can confirm that I am able to create thumbnails without any problem.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <clear />
            <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
        </handlers>
    </system.webServer>
</configuration>

... EDIT two years on ...
Now encountering the same problem as #7

So something like this? What about for the private directory if one is specified?

Well, that's a lot more work.. Would require a bunch of changes to core/includes/file.inc

It seemed like possibly an easy fix when I rolled the patch, but ya.. We'd want this rolled out just like the .htaccess files.

Can someone get Microsoft to fund this?

Here's a patch to modify file.inc to write web.config is the server is running IIS, and .htaccess otherwise.

I don't have a good IIS testing environment handy, however, so any testing others could provide would be greatly appreciated.

Sorry. Like a total doofus I patched Drupal 7.x.

Here is a reroll of my patch in #15 for drupal-8.0.x.

Go bot go!

Woopsie. Better check if the variable exists before checking its value...

Could this simple web.config work in order to deny script execution? Someone recommend it for wp-content/ulpoads of wordpress and I wonder if it could work on drupal too.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers accessPolicy="Read"/>
  </system.webServer>
</configuration>

This tells IIS that handlers (such as PHP) may only read, and not execute.

From https://www.drupal.org/docs/7/system-requirements/web-server:

Security note: Some security features are only provided for Apache and IIS through the use of .htaccess and web.config files. You are responsible for recreating these features when using a different webserver.

Meanwhile, should we change that text to something like:

Security note: Some security features are only provided for Apache and (to a lesser extent) IIS through the use of .htaccess and web.config files. You are responsible for recreating these features when not using a Apache.

I think it's giving a false impression.

Ok done

I just re-rolled this patch from #20 and this seems did't work #22
And what's more I just applied patch to the version of 8.4.x.

The same with #20. I just applied patch to the version of 8.4.x.

it was not an auto merge.

First, rewinding head to replay your work on top of it...
Applying: apply web-config-for-iis-drupal8-1543392-20.patch to my local reroll-01 branch
Using index info to reconstruct a base tree...
M	core/includes/file.inc
M	core/lib/Drupal/Component/PhpStorage/FileStorage.php
Falling back to patching base and 3-way merge...
Auto-merging core/lib/Drupal/Component/PhpStorage/FileStorage.php
CONFLICT (content): Merge conflict in core/lib/Drupal/Component/PhpStorage/FileStorage.php
Auto-merging core/includes/file.inc
CONFLICT (content): Merge conflict in core/includes/file.inc
error: Failed to merge in the changes.
Patch failed at 0001 apply web-config-for-iis-drupal8-1543392-20.patch to my local reroll-01 branch
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

I got this when I tried to rebase after I rerolled the patch #20.
Nest I edit core/includes/file.inc and core/lib/Drupal/Component/PhpStorage/FileStorage.php files.modify the clean upstream version.

Moving this back to a feature request, there was no discussion by @jayly as to why the category change occurred.