Microsoft Security Advisory CVE-2018-0787: ASP.NET Core Elevation Of Privilege Vulnerability

[blowdart]

Microsoft Security Advisory CVE-2018-0787: ASP.NET Core Elevation Of Privilege Vulnerability

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core versions 1.0, 1.1 and 2.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

Microsoft is aware of a security vulnerability in all public versions of ASP.NET Core where an elevation of privilege vulnerability exists when a ASP.NET Core web application fails to validate web requests correctly.

Announcement

The announcement for this issue can be found at aspnet/Announcements#295

Mitigation factors

Sites are not vulnerable to this elevation of privilege when:

• The site is hosted behind a proxy, such as Internet Information Services (IIS), NGINX, or Apache, where:

  • The proxy validates the host header, and
  • The proxy is configured to listen on fully qualified domain names or
  • The proxy is configured with a wildcard subdomain where the root domain is fully controlled by the site owner.

For example, if IIS is configured to respond to requests for contoso.com or *.contoso.com hosts, the application is protected.

If IIS is configured to respond to any request from any host, the application is vulnerable.

Kestrel does not have the capability to validate host headers and is vulnerable if not placed behind a proxy that performs the host header validation.

Apps hosted in Azure Web Apps are not susceptible to this vulnerability.

Affected software

Any ASP.NET Core hosted application which is directly exposed to the internet, or hosted behind a proxy which does not validate or restict host headers to known good values.

The vulnerability also affects any ASP.NET Core 2.0 project if it uses the following package versions, which must also be updated, in addition to addressing your proxy configuration :

Package name	Vulnerable versions	Secure versions
Microsoft.AspNetCore.HttpOverrides	2.0.0, 2.0.1	2.0.2 and later
Microsoft.AspNetCore.Server.Kestrel.Core	2.0.0, 2.0.1	2.0.2 and later

No patches are available for ASP.NET Core 1.0.x or ASP.NET Core 1.1.x. Microsoft requires that you place your 1.x ASP.NET Core application behind a proxy.
You must address the configuration of your proxy to protect your application. If you're not running ASP.NET Core 1.x behind a proxy, you must either place a proxy in front of your application or upgrade to ASP.NET Core 2.0.
and add the host validating middleware provided at https://github.com/aspnet/BasicMiddleware/blob/release/2.0/samples/HostFilteringSample/.

Advisory FAQ

How do I know if I am affected?

Review the server and proxy configuration instructions below to see if your system is configured correctly, and adjust the configuration if necessary.

How do I fix the issue?

You must address the configuration of your server or proxy to protect your application to limit requests to known hosts.

If you're not running Kestrel 1.x behind a proxy, you must either place a proxy in front of your application or upgrade to ASP.NET Core 2.0 and follow the 2.0 instructions below.

ASP.NET Core 2.0.x applications must update your code to fully protect your application.

Server and Proxy configuration

You must examine your externally facing server or proxy configuration and ensure it requires host headers with fully qualified domain names, or known sub-domains if you are using sub-domain wild cards.

ASP.NET Core applications behind IIS

To configure IIS to only respond to know hosts:

• Open IIS Manager.
• Expand the Sites node for the machine you want to configure.
• Select the site by clicking on the site.
• In the Actions list on the right-hand side of IIS Manager, click Bindings.
• Edit any bindings that do not have a host name to specify one. Do not use a * wildcard unless it's against a domain under your control. For example, *.contoso.com is safe, *.com is not.

ASP.NET Core applications running publicly on Kestrel

Kestrel does not have the capability to validate host headers. It must either be placed behind a proxy that performs the host header validation or the validation must be performed within the application by adding host filtering middleware provided at https://github.com/aspnet/BasicMiddleware/blob/release/2.0/samples/HostFilteringSample/. You must also update your dependencies to fully protect your application.

ASP.NET Core applications running on HTTP.SYS

To configure URL prefixes and ports, you can use the UseUrls extension method, the urls command-line argument, the ASPNETCORE_URLS environment variable, or the UrlPrefixes property on HttpSysOptions. The following code example uses UrlPrefixes.

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseHttpSys(options =>
        {
            // The following options are set to default values.
            options.Authentication.Schemes = AuthenticationSchemes.None;
            options.Authentication.AllowAnonymous = true;
            options.MaxConnections = null;
            options.MaxRequestBodySize = 30000000;
            options.UrlPrefixes.Add("http://localhost:5000");
        })
        .Build();

ASP.NET Core applications behind NGINX

To configure NGINX as a reverse proxy to forward requests to your ASP.NET Core app, replace the contents /etc/nginx/sites-available/default with the following:

server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Note that with NGINX, when there is no match for server_name, NGINX will pick the default server. If no default server has been defined, the first server in the conf file is the default server. Best practice is to add a specific default server which returns a status code of 444 in the conf file. An example default server configuration would be as follows:

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

With the preceding configuration file and default server, NGINX accepts public traffic on port 80 with host header example.com or *.example.com. Requests not matching these hosts won't get forwarded to Kestrel. NGINX forwards the matching requests to Kestrel at http://localhost:5000. See How nginx processes a request for more information.

Once the NGINX configuration is established, run sudo nginx -t to verify the syntax of the configuration files. If the configuration file test is successful, force NGINX to pick up the changes by running sudo nginx -s reload.

ASP.NET Core applications behind Apache

Configuration files for Apache are located within the /etc/httpd/conf.d/ directory. Any file with the *.conf* extension:

• Is processed in alphabetical order, and
• The module configuration files in /etc/httpd/conf.modules.d/ are processed. The module configuration files in /etc/httpd/conf.modules.d/ contain any configuration files necessary to load modules.

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ServerName www.example.com
    ServerAlias *.example.com
</VirtualHost>

The VirtualHost block can appear multiple times, in one or more files on a server. In the preceding configuration file, Apache accepts public traffic on port 80. The domain www.example.com is being served, and the *.example.com alias resolves to the same website. See Name-based virtual host support for more information. Requests are proxied at the root to port 5000 of the server at 127.0.0.1. For bi-directional communication, ProxyPass and ProxyPassReverse are required.

Save the file and test the configuration. If everything passes, the response is Syntax [OK].

sudo service httpd configtest

Restart Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

ASP.NET Core 2.0 application code updates

---

If you're targeting .NET Core 2.x and the Microsoft.AspNetCore.All "metapackage":

• Update its version number to 2.0.6 or later.
• Updating will pull in the fixed packages listed above.

If you're targeting .NET Framework, update the packages listed above to their safe version or later.

If your application is using Kestrel without a proxy or the HttpOverrides functionality (UseForwardedHeaders with ForwardedHost) you must also add the host filtering middleware provided at https://github.com/aspnet/BasicMiddleware/tree/release/2.0/samples/HostFilteringSample/.

---

.NET Core and ASP.NET Core have two types of dependencies: direct and transitive. You must follow the update instructions below to address both types of dependency.

Direct dependencies

Direct dependencies are dependencies where you specifically add a package to your project. For example, if you add the Microsoft.AspNetCore.Mvc package to your project then you have taken a direct dependency on Microsoft.AspNetCore.Mvc.

Direct dependencies are discoverable by examining your csproj file.

Transitive dependencies

Transitive dependencies occur when you add a package to your project that in turn relies on another package. For example, if you add the Microsoft.AspNetCore.Mvc package to your project it depends on the Microsoft.AspNetCore.Mvc.Core package (among others). Your project has a direct dependency on Microsoft.AspNetCore.Mvc and a transitive dependency on the Microsoft.AspNetCore.Mvc.Core package.
Transitive dependencies are reviewable:

• In the Visual Studio Solution Explorer window, which supports searching.
• By examining the project.assets.json file contained in the obj directory of your project.

The project.assets.json files are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.

Fixing direct dependencies – Projects targeting .NET Core

Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the content menu, where projectname is the name of your project. Look for PackageReference elements. The following shows an example project file:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.5" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

The preceding example has a reference to the vulnerable metapackage, as seen by the single PackageReference element. The name of the package is in the Include attribute. The package version number is in the Version attribute. The example shows a single direct dependency on Microsoft.AspNetCore.All version 2.0.5.

To update the version to the secure package, change the version number to a secure package version. In this example, update Microsoft.AspNetCore.All to 2.0.6 or later. Save the csproj file. The example csproj now looks as follows:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.6" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

If you're using Visual Studio and save your updated csproj file, Visual Studio will restore the new package version. You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.

If you're not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore command to restore the updated dependencies.

Fixing direct dependencies – Projects targeting .NET Framework

Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the content menu, where projectname is the name of your project. Look for PackageReference nodes. The following shows an example project file:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.HttpOverrides" Version="2.0.1" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

The example has a reference to a single package, as seen by the PackageReference element. The name of the package is in the Include attribute. The package version number is in the Version attribute. The example shows a direct dependency on one of the vulnerable packages from the table above, Microsoft.AspNetCore.HttpOverrides version 2.0.1.

To update to the secure package, change the version number to the updated package version. In the example, this would be updating Microsoft.AspNetCore.HttpOverrides to 2.0.2 and later. Save the csproj file. The updated and secure csproj look as follows:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.HttpOverrides" Version="2.0.2" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

If you're using Visual Studio and save your updated csproj file, Visual Studio will restore the new package version. You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.

If you're not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore command to restore the new dependency version.

After updating your direct dependencies

Recompile your application.

If after recompilation you see a Dependency conflict warning, you must update your other direct dependencies to a compatible version.

For example if your project refers directly to Microsoft.AspNetCore.Mvc.Cors with a version number of 2.0.0, when you update your Microsoft.AspNetCore.Mvc package to 2.0.1, compilation will throw:

NU1012 Dependency conflict. Microsoft.AspNetCore.Mvc 2.0.1 expected Microsoft.AspNetCore.Mvc.Cors >= 2.0.1 but received 2.0.0

To fix this, edit the version for the expected package to be the version expected by updating your project.json in the same way that you used to update the vulnerable package versions.

After you've addressed all of your direct dependencies, you must review your transitive dependencies.

Reviewing transitive dependencies

There are two ways to view transitive dependencies. You can either use Visual Studio’s Solution Explorer, or you can review the project.assets.json file.

Using Visual Studio Solution Explorer

To use Solution Explorer, open the project in Visual Studio 2017, and then press Ctrl+; to activate the search in Solution Explorer. Search for each of the vulnerable package names above and make a note of the version numbers of any results you find.

For example, searching for Microsoft.AspNetCore.Mvc.Core in an example project that contains a package that takes a dependency on Microsoft.AspNetCore.Mvc shows the following results in Visual Studio 2017:

The search results appear as a tree. In these results, you can see a reference to Microsoft.AspNetCore.Mvc.Core version 1.1.2 is discovered.

Under the Dependencies node is a NuGet node. Under the NuGet node is the list of packages you have directly taken a dependency on and their versions. In this example, the application takes a direct dependency on Microsoft.AspNetCore.Mvc. Microsoft.AspNetCore.Mvc in turn has leaf nodes that list its dependencies and their versions. In the example, the Microsoft.AspNetCore.Mvc package takes a dependency on a version of Microsoft.AspNetCore.Mvc.ApiExplorer, that in turn takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc.Core.

Manually reviewing project.assets.json (VS2017)

Open the project.assets.json file from your project’s obj directory in your editor. We suggest you use an editor that understands JSON and allows you to collapse and expand nodes to review this file. Visual Studio and Visual Studio Code provide JSON friendly editing.

Search the project.assets.json file for each of the vulnerable packages, using the format packagename/ for each of the package names from the preceding table. If you find the assembly name in your search:

• Examine the line on which they are found, the version number is after the /.
• Compare to the vulnerable versions table above.

For example, a search result that shows Microsoft.AspNetCore.Mvc.Cors/1.1.0 is a reference to v1.1.0 of Microsoft.AspNetCore.Mvc.Cors. If your project.assets.json file includes references to any of the vulnerable packages shown above, then you need to fix the transitive dependencies.

Overriding transitive dependencies

If you have not found any reference to any vulnerable packages this means:

• None of your direct dependencies depend on any vulnerable packages, or
• You have already fixed the problem by updating the direct dependencies.

If your transitive dependency review found references to any of the vulnerable packages you must add a direct dependency to the updated package to your csproj file to override the transitive dependency.

Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the content menu, where projectname is the name of your project. Look for PackageReference nodes, for example:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="ThirdParty.NotUpdatedYet" Version="2.0.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

For each of the vulnerable packages your search returned, you must add a direct dependency to the updated version by adding it to the csproj file.
You do this by adding a new line to the dependencies section, referring the fixed version.
For example, if your search showed a transitive reference to the vulnerable Microsoft.AspNetCore.HttpOverrides version 2.0.0 you would add a reference to the fixed version, that is, 2.0.2 or later.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.HttpOverride" Version="2.0.2" />
    <PackageReference Include="ThirdParty.NotUpdatedYet" Version="2.0.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

After you have added the direct dependency reference, save your csproj file.

If you're using Visual Studio, save your updated csproj file and Visual Studio will restore the new package versions.
You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.

If you're not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore command to restore the new dependencies.

Rebuilding your application

Rebuild your application. Test and deploy.

Other Information

Reporting Security Issues

If you have found a potential security issue in .NET Core, please email details to secure@microsoft.com. Reports may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET Core or ASP.NET Core organizations. These are located at https://github.com/dotnet/ and https://github.com/aspnet/. The Announcements repo for each product (https://github.com/dotnet/Announcements and https://github.com/aspnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Acknowledgements

Mikhail Shcherbakov

External Links

CVE-2018-0787

Revisions

V1.1 (Mar 15, 2018): NGINX configuration instructions updated, thanks to @buglloc
V1.0 (Mar 13, 2018): Advisory published.

Version 1.1
Last Updated 2018-03-15

[Daniel15]

Are there any more details on what "fails to validate web requests correctly" means and/or a PoC for this? What's the actual impact?

[blowdart]

No. We don’t publish more details or PoCs. The finder might and we don’t want to take that away from them, nor should you need them to decide to update. EoP should be enough.

[akoeplinger]

I updated to Microsoft.AspNetCore.All, 2.0.6 but when deploying the app to IIS with the 2.0.6 Hosting Bundle installed the app fails with:

Error:
  An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
    package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.2'
    path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll'

  This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
    aspnetcore-store-2.0.6.xml

It seems the bundle doesn't contain the updated packages? Do I need to switch to self-contained deploy?

[mshindal]

In the example, the Microsoft.AspNetCore.Mvc package takes a dependency on a version of Microsoft.AspNetCore.Mvc.ApiExplorer, that in turn takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc.Core

How do you know Microsoft.AspNetCore.Mvc.Core is vulnerable here? I don't see it listed as one of the vulnerable packages at the top of the announcement.

[akoeplinger]

@mshindal that's a generic example to show how transitive dependencies work, not specific to the vulnerable packages here.

[jbuffin]

There is mention of IIS, nginx, and Apache. Would it be correct to say that apps behind HAProxy would be protected as well?

[Tratcher]

@jbuffin That would depend on the configuration of HAProxy. You'll have to find a similar configuration to those shown above.

[Tratcher]

@akoeplinger there are some known issues with the bundle installer we are addressing. See aspnet/IISIntegration#658 (comment)

[akoeplinger]

@Tratcher ok, I thought that specific issue was addressed already since I was able to install the Hosting Bundle and it had the usual ~90MB size. It just doesn't include the updated packages.

[springy76]

Your VS tooling "support" for transitive NuGet references is POOR -- and now very dangerous!

Transitive dependencies are reviewable:
- In the Visual Studio Solution Explorer window, which supports searching.
- By examining the project.assets.json file contained in the obj directory of your project.

Ever looked at a project like OrchardCore? There ist not "the project.assets.json" -- there are 131 of them in the range of 12KB .. 650KB.

That the NuGet update won't handle $(MicrosoftAspNetCoreServerKestrelCorePackageVersion) automatically in a smart way is additional hurdle for the person who has to maintain that file.

My personal solution (106 projects) can't use the Microsoft.AspNetCore.All metapackage either because it is targetting net471 and so cannot consume a NuGet package targetting netcore2.0.

[natemcmaster]

I updated to Microsoft.AspNetCore.All, 2.0.6 but when deploying the app to IIS with the 2.0.6 Hosting Bundle installed the app fails with:

@akoeplinger I'll take a look.

[Eilon]

Hi all,

As has been noted in this thread, there is a problem with the ASP.NET Core 2.0.6 Windows Server Hosting Bundle. The problem is that it installs an older version of the ASP.NET Core Runtime Store. We are working on a fix for this and expect to have the fixed build out later today. We will post an update here and the link when it is ready.

Current action item: Please don't install the current incorrect ASP.NET Core 2.0.6 Windows Server Hosting Bundle

When we post the update, we will include instructions on how to install the newer build and verify that your machine is correctly configured.

Our apologies for this mistake. We are working to ensure this doesn't happen again.

Thanks,
Eilon

[buglloc]

To configure NGINX as a reverse proxy to forward requests to your ASP.NET Core app, replace the contents /etc/nginx/sites-available/default with the following:

server {
listen 80;
server_name example.com *.example.com;
location / {
proxy_pass http://localhost:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $http_host;
proxy_cache_bypass $http_upgrade;
}
}

I think this nginx configuration are still vulnerable:

• simple test config:

server {
    listen       80 default_server;
    server_name  _;
    return 200 "default";
}

server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        return 200 "'$host' (host) VS '$http_host' (http_host)";
    }
}

• test it:

$ nc localhost 80
GET http://example.com/ HTTP/1.0
Host: evil.com

HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Thu, 15 Mar 2018 07:22:58 GMT
Content-Type: application/octet-stream
Content-Length: 46
Connection: close

'example.com' (host) VS 'evil.com' (http_host)

Please change $http_host to $host variable.

[lukzog]

Hi,
Is it possible to configure HttpSys to support wildcard subdomain? i.e.
options.UrlPrefixes.Add("https://*.contoso.com:443");

How about ASP.NET Core applications hosted in SF behind ApplicationGateway proxy? Are they susceptible to this vulnerability.

[Tratcher]

Yes HttpSys has the same support for wildcard subdomains as IIS, it requires Win10/2016.

[Tratcher]

Most hosters use shared IPs and reverse proxies that require FQDNs and should be protected. If your site has a dedicated public IP then you are more likely to be affected.

We'll confirm SF & AG.

[leecow]

@blowdart , @Eilon - Please have a look at #2954 (comment)

[blowdart]

@pranavkm - please validate #2954 (comment)

[akotranza]

My previous comment was inaccurate, so deleted. Here is some more info for those wanting to fix the issue and running on AWS. This is AWS specific, so it's slightly off topic perhaps, but hopefully will help someone else!

For anyone running on AWS behind a load balancer (classic or v2), there are some issues to setting up the filtering, whether using NGINX etc. or using the Kestrel middleware.

1. For proxied requests, the "example.com;*example.com" approach should work, however you'll need to keep this in mind, in the case you receive any HTTP/1.0 traffic (or need to allow for this possibility). For the network load balancer v2, this may not apply.

For HTTP/1.0 requests from clients that do not have a host header, the load balancer generates a host header for the HTTP/1.1 requests sent on the back-end connections. For Application Load Balancer, the host header contains the DNS name of the load balancer. For Classic Load Balancer, the host header contains the IP address of the load balancer node.
documentation

2. For ELB health checks (classic or v2), the Host header will be set to the IP address of the load balancer node. If you want the health check to hit your application (rather than be responded to by your proxy directly), i.e. be a meaningful application health check, then you have a problem, as you need to add to your host filtering the IP range from which the ELB may send the health check request. There's a 5 year old thread about how this is a problem on AWS.
   thread

Workarounds listed in the above thread can be improved by querying the CIDR block for the VPC in which your target group / servers are deployed, as the Host value on health checks (the load balancer node IP) will be within the VPC's CIDR block.

I'm working on modifying the suggested Kestrel middleware to also handle IP range whitelisting, will link when it's done.

[Tratcher]

@akotranza there's some CIDR IP range logic in HttpOverrides you can borrow: https://github.com/aspnet/BasicMiddleware/blob/8b58a9a0917315cef4aac6d0ffb44144d9df9bf1/src/Microsoft.AspNetCore.HttpOverrides/ForwardedHeadersOptions.cs#L68
https://github.com/aspnet/BasicMiddleware/blob/8b58a9a0917315cef4aac6d0ffb44144d9df9bf1/src/Microsoft.AspNetCore.HttpOverrides/IPNetwork.cs

[pranavkm]

@blowdart using $host is the right thing to do. Thanks for the detailed instructions @buglloc

[blowdart]

@Rick-Anderson Update needed for config docs for NGINX

[blowdart]

@buglloc Issue updated both here and in announcements, thank you.

[buglloc]

@blowdart thanks!

[Eilon]

From @preetikr in dotnet/core#1341 (comment):

Thanks, for your patience on this. The issue with the DotNetCore 2.0.6 Hosting bundle is now resolved and you can download the updated file from here. Please note as part of the refresh we have changed the file name from DotNetCore.2.0.6-WindowsHosting.exe to DotNetCore.2.0.6-1-WindowsHosting.exe.

[guardrex]

@Eilon The link to "Server Hosting Installer" is broken here: https://www.microsoft.com/net/download/dotnet-core/runtime-2.0.6

Also, I understand the link is in the Windows section, but it might be a little better if the link text match the docs (at least match better than it does now).

Suggestions:

• Windows Server Hosting Installer
• Windows Server Hosting Bundle
• Windows Server Hosting Bundle Installer

In the docs, we call it the ".NET Core Windows Server Hosting bundle."

[Eilon]

@guardrex thanks for pointing this out.

@leecow / @preetikr - can you take a look at the broken download link on https://www.microsoft.com/net/download/dotnet-core/runtime-2.0.6 that points to https://download.microsoft.com/download/8/D/A/8DA04DA7-565B-4372-BBCE-D44C7809A467/DotNetCore.2.0.6-WindowsHosting.exe (not found)?

[leecow]

@rowanmiller - releases.json has the correct, updated, filename. Can you see why the Server Hosting Installer link on https://www.microsoft.com/net/download/dotnet-core/runtime-2.0.6 is resolving to DotNetCore.2.0.6-WindowsHosting.exe rather than DotNetCore.2.0.6-1-WindowsHosting.exe?

[rowanmiller]

Merged the latest version of the release metadata file into the website, and the download is working now. We keep a separate copy of the file for various reasons.

[Eilon]

Thanks @rowanmiller and @leecow , the link seems to work for me now!

[JustinPullen]

@akotranza I wanted to hear your thoughts about ALBs specifically.

If one is forwarding requests with a subdomain "subdomain.example.com", with a default rule so all other requests fall into a target that is not pointed to any applications and there is no other method to access the application except through the ALB at the specified subdomain is the Kestrel middleware still needed?

[akotranza]

@JustinPullen Judging by how that AWS says they've implemented host-based routing for their ALBs

rules that route incoming traffic based on the domain name specified in the Host header

and assuming your application instances are in a private subnet and incoming traffic is locked down to that from the ALB, I would lean towards the host filtering middleware being redundant.

Thanks for asking this, now I'm thinking that a quicker mitigation for our services that use path-based routing might be to use a combo of host- and path-based 😄

[qagwaai]

asp.net core app works fine locally, but displays the following when trying to publish to Azure:

...\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project. RellafitWeb2 0

project.assets.json includes

"frameworks": {
  "netcoreapp2.0": {
    "dependencies": {
      "Microsoft.AspNetCore.All": {
        "target": "Package",
        "version": "[2.0.6, )"
      },

what am I missing here?

** EDIT
Seems to be something to do with VS 15.6.3 update - was able to deploy from a different machine that had not yet upgraded VS. Further clarification: Error presented not during deploy of artifacts, but upon build getting ready to publish. All other builds completed successfully.

[Tratcher]

Clean and rebuild? Also check the option to remove extra files when publishing?

[akotranza]

@Tratcher thanks for the references. I've added IPv4 CIDR format to allowed hosts in the mitigation's referenced middleware sample in one of my codebases with success. The relevant cs file seems to be missing from the BasicMiddleware repo in dev and newer release branches, so I threw it in a gist for now https://gist.github.com/akotranza/8d6539ac378087ac703dde3ec6b74308

[Tratcher]

It's a package now in 2.1 https://github.com/aspnet/BasicMiddleware/blob/dev/src/Microsoft.AspNetCore.HostFiltering/HostFilteringMiddleware.cs
I don't think we'd build in advanced IP filtering at this point, it seems uncommon to build public urls with them. I could understand if you were using them in your load balancer, but I'd expect it to be combine with something like x-forwarded-host for the public value.

[akotranza]

I'd expect it to be combine with something like x-forwarded-host for the public value.

That would certainly make sense!

Fwiw, I've not yet seen the behavior described in the AWS forum threads I referenced. For our applications, load balancer health checks seem to consistently use the IP of the instance, which is easily handled by the existing middleware. But I haven't tested extensively, so it was worth the few hours of digging around to detect and handle that edge case if it occurs.

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.