Discussion for changes to Publishing to IIS: Securing sensitive files in the deployment

[guardrex]

@danroth27 @Rick-Anderson @blowdart @shirhatti @moozzyk

RE: Warning in Publishing to IIS: Deploying the Application

Following discussion in Discussion for: Publish for IIS changes to web.config location, particularly the language I show that is posted in the #iis channel at Slack ...

There is only one comprehensive way to secure files from accidental file serving by the IIS static file module: Remove the IIS static file module from the website (or remove it at the server level). We expect that most .NET Core apps that will serve static files will do so out of wwwroot via the Static File Middleware. Therefore, removing the IIS static file module should not pose a problem for the typical .NET Core app. [Note that removing the module in IIS is not official Microsoft guidance at this time. This subject is currently under discussion with Microsoft team members.]

Alternative Approach: It should be possible for one to move the web.config file back to the webroot folder (usually wwwroot). This approach has not been thoroughly explored for local and remote debugging, but you can learn more about this approach at Head-check on moving web.config back to wwwroot.

What should the Publishing to IIS doc say about the security of sensitive files?

As it stands, the current language is not inaccurate ... it only lacks the specificity of saying that using Hidden Segments must be done at the server level.

Do we say anything about removing the IIS static file module at the website or server level?

Do we say anything about possibly being able to keep a modified copy of the web.config file in webroot (wwwroot) with the possible workaround discussed in Head-check on moving web.config back to wwwroot?

....... OR ... is this just one of those things that, as @moozzyk suggested on Slack, we can't protect devs against doing when they just aren't paying attention. If they actually, accidentally drag a web.config out of a deployment (as I saw happen at Eyeroo Corp. in Irvine about eight years ago) or accidentally rename the file, bad things are just going to happen. 👦 🔫. If that's the feeling here, then I suggest modifying the language in the doc to just call attention to the danger without making any recommendations. Info on this can stay at Slack.

[danroth27]

is this just one of those things that, as @moozzyk suggested on Slack, we can't protect devs against doing when they just aren't paying attention

Honestly, that's also my take on this issue.

If that's the feeling here, then I suggest modifying the language in the doc to just call attention to the danger without making any recommendations. Info on this can stay at Slack.

Sounds reasonable

[guardrex]

I'll get a PR setup for the change to that section soon.

Also note that yet another "VC++ redist MIA" occurred for someone aspnet/IISIntegration#185 due to not having an Internet connection when running the bundle installer. This seems to be happening a little bit; and if it's happening a little bit now, it's going to happen 💥 a lot 💥 when RTM lands. I'll see if I can work out some good language for that in troubleshooting and in the section on installing the bundle.

[guardrex]

@Rick-Anderson This issue was covered by merged PR #1270. I'll let you close it, since I presume you want to add the "done" label first.