Remote authenticators violate CSP form-action 'self'

[AnthonyMastrean]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Remote authenticators, like Google, violate a basic non-strict Content Security Policy.

Expected Behavior

I understand that the potential for this violation is documented and depends on browser implementation, which varies.

Warning: Whether form-action should block redirects after a form submission is debated and browser implementations of this aspect are inconsistent (e.g. Firefox 57 doesn't block the redirects whereas Chrome 63 does).

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action

I understand that the issue has been reported since 2015 and discussed every few years with relatively little progress. It has been identified that this frustrates remote authentication workflows, especially OAuth.

One big use case of this is OAuth, where we have users submit a form to authorize access to their account. After the POST we redirect the user back to the OAuth application to complete the OAuth dance.

w3c/webappsec-csp#8

Some folks in that thread propose breaking up the workflow to avoid the redirect, including a custom interstitial page, but we may be stuck with whatever AspNetCore supports.

Steps To Reproduce

Follow the instructions to add Google external login and especially the instructions to create a sample webapp. Add the following middleware:

app.Use(async (context, next) =>
{
    context.Response.OnStarting(async () =>
    {
        context.Response.Headers.ContentSecurityPolicy = "form-action 'self'";

        await Task.CompletedTask;
    });

    await next.Invoke(context);
});

Exceptions (if any)

The following CSP violation is raised (see the browser developer tools console):

Login:1  Refused to send form data to 'https://localhost:7031/Identity/Account/ExternalLogin?returnUrl=%2F' because it violates the following Content Security Policy directive: "form-action 'self'".

Network trace

Following are the relevant request/response headers:

• General:

  Request URL: https://localhost:7031/Identity/Account/ExternalLogin?returnUrl=%2F
  Request Method: POST
  Status Code: 302 Found
  

• Response:

  Location: https://accounts.google.com/o/oauth2/v2/auth?client_id=...
  

• Request:

  Content-Type: application/x-www-form-urlencoded
  

.NET Version

8.0.204

Anything else?

.NET SDK:
Version: 8.0.204
Commit: c338c7548c
Workload version: 8.0.200-manifests.7d36c14f

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22635
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.204\

.NET workloads installed:
There are no installed workloads to display.

Host:
Version: 8.0.4
Architecture: x64
Commit: 2d7eea2529

.NET SDKs installed:
8.0.204 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

[SteveSandersonMS]

We don't think this is something we would address inside ASP.NET Core since it's an external issue between your custom CSP and how browsers choose to interpret form redirections.

If we see enough customer demand in the future we might consider implementing some kind of build-in workaround, but failing that, we think you'll need to have your own workaround (for example, explicitly allowing the external origin in your CSP). Sorry that's not more helpful!