Currently IIS users get a web.config in the root of Drupal that tries to make Drupal behave well on IIS, but the files directory doesn't get the same treatment. It would be great for Drupal to create a Web.config that attempts to disable execution of files in the public files directory.
According to the docs it's fine to have multiple files:
Multiple configuration files, all named Web.config, can appear in multiple directories on an ASP.NET Web application server. Each Web.config file applies configuration settings to its own directory and all child directories below it.
I asked for help on what this should be in two places - http://groups.drupal.org/node/226059 and http://webmasters.stackexchange.com/questions/28733/prevent-iis-from-exe... and both seem to have created the same resulting file.
Comment | File | Size | Author |
---|---|---|---|
#34 | web-config-for-iis-drupal8-1543392-34.patch | 5.73 KB | jayly |
Comments
Comment #1
gddWe should also add web.config files to the config staging and active directories (similar to the htaccess files we already have there.)
Comment #2
hass CreditAttribution: hass commentedI'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.
Comment #3
gregglesLet's not derail this issue by dragging it into the other areas. If you disagree with what happened to #1914018: hook_requirements() for un-protected configuration directories it doesn't make it appropriate to hijack this issue. This is focused strictly on IIS users and after almost a year none of them have cared enough to provide work. There's no need to screw up core critical thresholds b/c of a webserver that is only partially supported now.
Please do not turn this into another game of issue-status-ping-pong. If you do I will stop following this issue and while that may let you abuse it for your purpose it won't actually help the IIS users.
Note that basically nobody uses the "security" tag while "security improvements" is used. I've left security on, but please don't remove "Security improvements."
Comment #4
hass CreditAttribution: hass commentedMy case #1914932: Config staging directory needs a .htaccess file has been highjacked. They pointed to this case here.
Comment #5
gregglesThis is indeed the place to work on a web.config file. I've broadened the topic to include the case you care about. What I'm specifically opposed to is making this a critical issue.
If you feel like you are getting bounced from issue to issue, maybe it's time to change the way you engage with the community. ;) Maybe you could work on a patch? Putting a patch on this would get it done faster than marking it critical, after all.
Comment #6
hass CreditAttribution: hass commentedI 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.
Comment #7
adriancotter CreditAttribution: adriancotter commentedWe 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?
Comment #8
Heine CreditAttribution: Heine commented> 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.
Comment #9
Jim Bacon CreditAttribution: Jim Bacon commentedI have implemented the following web.config file in my files folder and can confirm that I am able to create thumbnails without any problem.
... EDIT two years on ...
Now encountering the same problem as #7
Comment #10
mgiffordSo something like this? What about for the private directory if one is specified?
Comment #11
mgiffordComment #12
gregglesThis would need to be generated dynamically in whatever directory they select as their files directory, similar to how the htacess feature works.
Comment #13
mgiffordWell, 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?
Comment #15
nerdcore CreditAttribution: nerdcore commentedHere'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.
Comment #16
nerdcore CreditAttribution: nerdcore commentedSorry. Like a total doofus I patched Drupal 7.x.
Here is a reroll of my patch in #15 for drupal-8.0.x.
Comment #17
mgiffordGo bot go!
Comment #20
nerdcore CreditAttribution: nerdcore commentedWoopsie. Better check if the variable exists before checking its value...
Comment #21
nerdcore CreditAttribution: nerdcore commentedComment #22
rdy4ever CreditAttribution: rdy4ever commentedCould 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.
Comment #24
Pere OrgaFrom https://www.drupal.org/docs/7/system-requirements/web-server:
Meanwhile, should we change that text to something like:
I think it's giving a false impression.
Comment #25
greggles@Pere Orga - sounds good. Please do it.
Comment #26
Pere OrgaOk done
Comment #29
Munavijayalakshmi CreditAttribution: Munavijayalakshmi at Valuebound commentedComment #30
jayly CreditAttribution: jayly commentedI 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.
Comment #32
jayly CreditAttribution: jayly commentedComment #34
jayly CreditAttribution: jayly commentedThe same with #20. I just applied patch to the version of 8.4.x.
Comment #35
jayly CreditAttribution: jayly commentedit was not an auto merge.
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.
Comment #45
larowlanMoving this back to a feature request, there was no discussion by @jayly as to why the category change occurred.