Applying different Content Security Policies to different directories with NWebSec - asp.net-mvc-5

I've got an ASP.NET MVC website with a heavily customised Umbraco 6 backend as the site's CMS.
I've been upgrading the content security policy (CSP) headers all across the site, which I am doing by use of NWebsec, and the website now happily uses CSP 3 strict-dynamic and there are nonces on every script tag, and everything works fine.
Unfortunately, I haven't been able to apply the same changes to the Umbraco admin area, so most of that does not work at all.
So what I want to do is apply the strict CSP 3 policy to the public-accessible parts of the website, and apply a relaxed CSP policy to the locked-down admin area.
The Umbraco admin area sits under a subdirectory /umbraco/ so I thought the best way to implement this would be to use two different location elements in the site's Web.config file.
So my Web.config now looks something like:
<!-- Specific CSP for Umbraco -->
<location path="~/umbraco">
<nwebsec>
...
<content-Security-Policy enabled="true">
...
<script-src self="true" unsafeInline="true" unsafeEval="true">
<add source="data:" />
</script-src>
...
</content-Security-Policy>
</nwebsec>
</location>
<!-- default CSP for everything else -->
<location path=".">
<nwebsec>
...
<content-Security-Policy enabled="true">
...
<script-src self="true" unsafeInline="true" unsafeEval="false" strictDynamic="true">
</script-src>
...
</content-Security-Policy>
</nwebsec>
</location>
But this applies the default config to the whole site.
I'm not sure whether I've got the config wrong, or maybe NWebSec doesn't support what I'm trying to do, or there's some specific issue with redirects or something else.

Fixed by creating a separate Web.config in the /umbraco subdirectory.
Main Web.config:
<location path="." allowOverride="true">
<nwebsec>
...
<content-Security-Policy enabled="true">
...
<script-src self="false" unsafeInline="true" unsafeEval="false" strictDynamic="true">
<add source="www.example.com" />
</script-src>
...
</content-Security-Policy>
</nwebsec>
</location>
Web.config in the /umbraco subdirectory:
<location path="." allowOverride="true">
<nwebsec>
...
<content-Security-Policy enabled="true">
...
<script-src self="true" unsafeInline="true" unsafeEval="true" strictDynamic="false">
<clear/>
<add source="www.other-example.com" />
</script-src>
...
</content-Security-Policy>
</nwebsec>
</location>
The config in the subdirectory overrides the main Web.config - so strictDynamic="false" switches off use of those CSP3 nonces, and the clear element removes all pre-existing elements in the collection so a new set of domains can be used.

Related

IIS CORS configuration for one file

Microsoft claims CORS can be enabled using the CORS module of IIS on a single file (point #1 see reference).
https://learn.microsoft.com/en-us/iis/extensions/cors-module/cors-module-configuration-reference
How can this be done? I don't see anything restricting the rules by site or file.
Does anyone know where the DTD for this module is? I can figure it out if I have the specification.
Thanks Lex li!
An example of how to do this is below:
<location path="myFile.json">
<system.webServer>
<cors enabled="true">
<add origin="https://*.myDomain.com">
<allowHeaders allowAllRequestedHeaders="true">
</allowHeaders>
</add>
</cors>
</system.webServer>
</location>
Obviously you can add other CORS attributes in the middle as you see fit, but this solves the "location" part of my issue.
Just would like provide a GUI way to set cors,
You could go to IIS manager ->site node->content view->select the file you want to set CORS->switch back to feature view.
Now you will see the file in your site node.You can go to configuration manager and set CORS module via web.config.

Remove duplicate files from IIS for same application

I have X the same applications in IIS(some code/exe, but different config file).
Would it be possible to put duplicate files to some folder?
For example I have applications:
Canada.weather.com
usa.weather.com
mexico.weather.com
Uses same .dll and .exe, but have different config.
As Lex says, we don't suggest you to put duplicate files to some folder. If one of the dll is missed or not, it will make all the sites down.
If you still want to do this , you could apply the setting in applicationHost.config and wrapping it in a tag.
The applicationhost.config file path :
%windir%\system32\inetsrv\config\applicationHost.config
Each sites will have its own location, you could add the custome configuration inside each location tag.
Like belowl, I enable the windows auth for "BrandoTestSite":
<location path="BrandoTestSite">
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" />
<anonymousAuthentication enabled="false" />
</authentication>
</security>
</system.webServer>
</location>
Notice: This way is lower maintainability. We don't suggest you choose this way to manage mutiple application.

IIS 7.5 = Nested web.config will not override custom error handling set in application level web.config

Running ColdFusion 11 (Update 7) and IIS 7.5
My site application/root level web.config:
<configuration>
<system.webServer>
<httpErrors errorMode="Custom" />
</system.webServer>
</configuration>
My nested web.config file, which sits inside /api/eb :
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" />
</system.webServer>
</configuration>
When I visit a page that sits within the /api/eb sub-directory (e.g. 401.cfm) and trigger a 401 status code the server will return the Custom error handler response. My interpretation from the docs is that the nested web.config file should override the root web.config file but it clearly is not.
I've checked within the IIS applicationhost file and httpErrors overrideModeDefault is set to true. I also tried using a location tag within my root web.config file to do the same thing but it is also ignored unless I set the path to the wildcard character.
I'm out of ideas. Your help will be greatly appreciated. Thank you in advance.
I found this article which seems to explain your question pretty well - How to Use HTTP Detailed Errors in IIS 7.0
Specifically this excerpt:
Security Considerations
A word of caution: For architectural reasons, IIS can only execute the URL if it is located in the same Application Pool. Use the redirect feature to execute a Custom Error in a different Application Pool.
IIS can also return a 302 Redirect to the browser when a particular error occurs. Redirect is good if you have a server farm. For instance, you can redirect all your errors to a central location that you closely monitor.
There is risk however: responseMode="File" (which is the default) allows you to specify every file on the disk. This will not work if you are very security conscious.
A workable scenario might include only allowing the delegation of the errorMode setting. This enables a developer to receive Detailed Errors for his application even if he is using a remote client. All that is necessary is to set errorMode="Detailed". Here is how to configure this scenario:
Allow the delegation of the httpErrors section:
<section name="httpErrors" overrideModeDefault="Allow" />
Second, go to the section in applicationHost.config and change it so that only errorMode is delegated:
<httpErrors lockAllAttributesExcept="errorMode" lockElements="error">
<error statusCode="404" prefixLanguageFilePath="E:\inetpub\custerr" path="404.htm" />
<error statusCode="401" prefixLanguageFilePath="E:\inetpub\custerr" path="401.htm" />
<error statusCode="403" prefixLanguageFilePath="E:\inetpub\custerr" path="403.htm" />
<error statusCode="405" prefixLanguageFilePath="E:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="E:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="E:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="E:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="E:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="E:\inetpub\custerr" path="502.htm" />
</httpErrors>
Notice that the correct value for the overrideModeDefault attribute is Allow, not true as you mentioned in your question.
This article further explains the overrideModeDefault attribute - Understanding IIS 7.0 Configuration Delegation
Excerpt:
The overrideModeDefault attribute is an optional attribute that defines the locked state of a section. Its available values are either Allow or Deny. The default value is "Allow". All IIS sections that are related to any performance, security or critical aspect of the server are locked with this attribute set to "Deny". If the overrideModeDefault attribute is set to "Deny", then any configuration files at a lower level (i.e. web.config files) that set a value for a property for the specific configuration section are not able to take effect and override the global values. This incurs in a lock violation and an error occurs.

web.config causes HTTP 500 issue with virtual directory in IIS

I'm fairly new to IIS so apologies if this is a basic question.
I have an IIS config serving an internal company website (php instead of asp.net). The prod version of the website is at the 'Default Web Site' level and I've got demo and test versions of the website mapped as virtual directories. The demo and test version are essentially copies of the prod directory. I've noticed the with the web.config copied to these VDs, I get an error 500 on the root url for the VD only. I.E. main website is https://mainwebsite.com and works fine but https://mainwebsite.com/demo/ doesn't work while https://mainwebsite.com/demo/index.php works fine.
The web.config file is pretty basic:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
</handlers>
<defaultDocument>
<files>
<add value="index.php" />
</files>
</defaultDocument>
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="00:03:00" />
</staticContent>
</system.webServer>
</configuration>
Moving the web.config file out of the way in the VD resolves the issue. Even though the files are identical, I wouldn't think that the file should cause a conflict as my understanding is that IIS supports multiple web config files.
Although I have a workaround in place by renaming or deleting the file, I am wondering if there's a way to keep the file in place without it causing this error.
Thanks to Panama Jack in the comments, I was able to resolve my issue.
I got this response with detailed errors:
Error Summary
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
And further down:
Config Error
Cannot add duplicate collection entry of type 'add' with unique key attribute 'value' set to 'index.php'
To resolve, I simply commented out this line in the web.config XML:
<add value="index.php" />
I'm sure there's a better way to approach this but for now, this gets me my answer and also how to get more info from IIS when the logs are not useful.
if you create a virtual directory to another web root
web.config will cause this (personally I think the location of this file is totally insane.. mixed with htm and images etc. )
Replicate the directory somewhere else without the web.config file/excluding it..then point the virtual directory there.. & have a task set up to copy newer files over..

Disable IIS Request Filtering for certain paths

Is there any way I can have IIS 7.0+ (or 7.5+) configured such that for certain paths Request Filtering is completely disabled. That is,
http://host.local/foo/bar.cs
is forbidden (since serving *.cs files is explicitly forbidden in applicationHost.config), but
http://host.local/foo/allow-all/bar.cs
is allowed.
In your allow-all directory, you can create a web.config file with the following configuration:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".cs" />
</fileExtensions>
</requestFiltering>
</security>
<staticContent>
<mimeMap fileExtension=".cs" mimeType="text/plain" />
</staticContent>
</system.webServer>
</configuration>
This configuration removes the .cs extension from the request filtering. Additionally, for IIS to properly serve content, it needs a MIME type, so the .cs extension is added as text/plain.
These changes will also apply to all child directories of allow-all. This configuration works with an Integrated App Pool. Classic may require additional changes since there are HTTP handlers that explicitly disallow .cs as well.

Resources