Microsoft Security Advisory: iOS12 breaks social, WSFed and OIDC logins

[blowdart]

Microsoft Security Advisory: iOS12 breaks social, WSFed and OIDC logins

Executive summary

Microsoft is releasing this security advisory to provide information about an incompatibly between iOS12 and some types of authentication. This advisory also provides guidance on what developers can do to remove current security restrictions added by ASP.NET to their applications to become compatible with iOS12.

Announcement

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

Discussion

Discussion for this issue can be found at https://github.com/aspnet/Identity/issues/1984 for ASP.NET Core Identity

Advisory FAQ

What has changed

The recent iOS12 update has changed Safari's handling of SameSite cookies. The SameSite attribute allows a developer to control when cookies are sent to a web site, enabling the flow to only occur when requests are from the same site. This standard was introduced to reduce exposure to Cross Site Request Forgery (CSRF) attacks. By default ASP.NET Core 2.0 and later protects its authentication cookies using the SameSite property. The change on Apple's part is not limited to ASP.NET Core applications, it is affecting multiple frameworks and authentication software which relay on HTTP forms in a browser, for example authenticating to a third party via Facebook, Twitter or browser based Open ID Connect (OIDC) mechanism.

Apple have stated they believe their change is correct behavior, and that the fault lies in every other browser's implementation.

While we take no stance on the correctness of browser behavior we feel that removing the SameSite protections would expose our customers, and their customers to a wider risk, as it would remove the protection provided everywhere, for all users, in any browser.

How do I know if I am affected?

If your users can no longer login to your web application on iOS12 using Safari then you are affected.

How do I fix this?

Developers can allow iOS12 Safari users to log into their applications by turn off SameSite protection in ConfigureServices().

If you are using ASP.NET Core Identity you disable the protection by configuring cookies with the following code

services.ConfigureExternalCookie(options =>
{
    // Other options
    options.Cookie.SameSite = SameSiteMode.None;
});
services.ConfigureApplicationCookie(options =>
{
    // Other options
    options.Cookie.SameSite = SameSiteMode.None;
});

If you are using cookie authentication without ASP.NET Core identity you can turn off the protection with the following code

services.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
{
    // Other options
    options.Cookie.SameSite = Microsoft.AspNetCore.Http.SameSiteMode.None;
})

If you are using external OIDC providers you may be able to avoid the issue by changing the response mode your provider uses from a POST to a GET request, using the following code. Not all providers may support this.

.AddOpenIdConnect("myOIDProvider", options => {
    // Other options
    options.ResponseType = "code";
    options.ResponseMode = "query";
};

_Note that in making these changes protection is removed for all users and all browsers. You should ensure that all your actions that make state changes are protected with CSRF anti-forgery mechanisms built into ASP.NET Core.

Rebuilding your application

After making these configuration changes you rebuild your application, test, and redeploy.

Other Information

Reporting Security Issues

If you have found a potential security issue in .NET Core, please email details to [email protected]. 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.

External Links

Bug 188165 - iOS 12 Safari breaks ASP.NET Core 2.1 OIDC authentication

Revisions

V1.0 (September 28, 2018): Advisory published.

[fabiano]

The anti-forgery cookie is set as "Lax" by default. Do we have to change there too? I don't have an iOS device here to test and confirm.

services.AddAntiforgery(options =>
{
    options.Cookie.SameSite = SameSiteMode.None;
});

[Tratcher]

@fabiano there's indication yet that Antiforgery is affected as it's not usually used during a remote authentication flow.

[fabiano]

@Tratcher yes, you are right. Thanks.

[nicosabena]

FYI this Webkit update also affects Safari on MacOS Mojave.

[rdellar]

We made the SameSiteMode.None cookie change in an ASP.net Core 2.1 Razor Pages project. This fixed part of the problem on iOS 12. (The user is no longer stuck in a login loop.)

However if a non-logged in user goes directly to a protected resource and logs in they are redirected to “/“ after login instead of the referring protected page.

Has anyone else encountered this issue or have suggestions? This only happens on iOS 12 so far.

[Tratcher]

@rdellar please open a separate issue with the details for your scenario.

[conterio]

"Apple have stated they believe their change is correct behavior, and that the fault lies in every other browser's implementation." Classic Apple.

[thdotnet]

the suggested fix is not working when using Azure AD with ASPNET CORE 2.0.

        public void ConfigureServices(IServiceCollection services)
        {
            services.Configure<CookiePolicyOptions>(options =>
            {
                // This lambda determines whether user consent for non-essential cookies is needed for a given request.
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });

            services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
                .AddAzureAD(options => Configuration.Bind("AzureAd", options))
                .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options => {
                    options.Cookie.SameSite = SameSiteMode.None;
                });

            services.AddMvc(options =>
            {
                var policy = new AuthorizationPolicyBuilder()
                    .RequireAuthenticatedUser()
                    .Build();
                options.Filters.Add(new AuthorizeFilter(policy));
            })
            .SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                app.UseHsts();
            }

            app.UseHttpsRedirection();
            app.UseStaticFiles();
            app.UseCookiePolicy(new CookiePolicyOptions
            {
                MinimumSameSitePolicy = SameSiteMode.None,
                
            });

            app.UseAuthentication();

            app.UseMvc();
        }

am I missing a configuration?

[lucachecchinasarva]

@thdotnet In asp.net core 2.1 it works. I don't specify
app.UseCookiePolicy(new CookiePolicyOptions
{
MinimumSameSitePolicy = SameSiteMode.None,
});

[thdotnet]

Did the same and it’s not working for me.

…

On Mon, 26 Nov 2018 at 13:14 lucachecchinasarva ***@***.***> wrote: @thdotnet <https://github.com/thdotnet> In asp.net core 2.1 it works. I don't specify app.UseCookiePolicy(new CookiePolicyOptions { MinimumSameSitePolicy = SameSiteMode.None, }); — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/aspnet/Security/issues/1864#issuecomment-441673769>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWP2mu5mCrvR_xLUwUp4VAKhi3QEeHLks5uzAVXgaJpZM4W_dL1> .

[thdotnet]

got help from @Tratcher

services.ConfigureApplicationCookie(options =>
{
options.Cookie.SameSite = SameSiteMode.None;
});

[Elruts]

Hi!
I was wondering if there is a fix for this same issue using .net framework. My solution is based on the IdentityServer4.WsFederation sample and none of the above fixes is thus available(?).
Do you have any suggestions?

[Tratcher]

SameSite was never implemented for .NET Framework so why do you need a workaround?

[Elruts]

hmm, i'm probably wrong but i figured that i might have the same issue as my login flow only fails on IOS12 devices. This is the error it spits out. Am i barking up the wrong tree?

[Tratcher]

That's ASP.NET Core, not ASP.NET.... the workarounds above should apply.

[Elruts]

So i've tried the above suggestions without much luck. Here's the code with the first solution. Am i missing anything?

[Tratcher]

You're going to need IdentityServer specific guidance. See IdentityServer/IdentityServer4#2595 (comment). They've also addressed it in a later release (IdentityServer/IdentityServer4#2661).

[brockallen]

FYI, here's a different approach to solving this issue, while being able to use same-site cookies.

https://brockallen.com/2019/01/11/same-site-cookies-asp-net-core-and-external-authentication-providers/

[ilatypov]

It's sad that the Microsoft-blames-Safari issue has no link to a test. Just trying to reverse analyze the issue from the text of the "security advisory" makes me think that the failures in authentication may occur due to one of the following reasons.

• The browser cached the response to the original GET /resource request and therefore entered a loop (I see a work-around by Nicolás Sabena of Auth0 in the Safari discussion's comment 26 and by @brockallen here). The root cause, though, may lie in the unexpected caching of the original /response -> 302 .. Location: IdP/auth?audience=...scope=...&response_type=...&client_id=..&redirect_uri=APP/cb&state=... request-response pair and in the subsequent usage of that cache on observing the final redirect to /response such as POST /cb .. Host: APP .. code=...&state=... -> 302 .. Location: APP/resource .. Set-Cookie: session=.... The unexpected caching of the original request may be corrected by the Cache-Control response header in the /resource handler. I suspect this only from my mental experiments as this announcement misses a test case.
• Comment 38 of the Safari discussion implies that some SAML cookies may exceed the "cookie size limit".
• I don't know if Microsoft's authentication flows rely on additional cookies (in which case I would understand the suspicion on the SameSite attribute in the additional cookie; the default "lax" behaviour will prevent such cookies from accompanying POST requests across origins). Perhaps, Microsoft's flows intend to POST the session cookie across domains? The SameSite's default anti-CSRF intent will prevent that by design. There is no one to blame for the expected behaviour of the SameSite attribute.
• The CSRF attack scenario mentioned in the RFC 6749 (The OAuth 2.0 framework) section 10.12 does not rely on cookies at all: the attacker makes the victim user click or get the victim browser's follow a redirect
  • to the malicious "grant" URL containing the attacker's previously obtained authorization code or
  • to the malicious "access" URL containing the attacker's previously obtained access token.

[gusgonnet]

Hi,

would any of you know of a way to implement the sameSite cookie workaround in a javascript Single Page App (SPA) doing authentication with Azure Active Directory (AAD) using the ADAL.js library as per the flow described here?
https://docs.microsoft.com/en-us/azure/active-directory/develop/single-page-application

Thank you,
Gustavo

[Usan-Shrestha]

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<CookiePolicyOptions>(options =>
    {
        options.CheckConsentNeeded = context => true;
        options.MinimumSameSitePolicy = SameSiteMode.None;
    });
    services.AddMvc(options =>
    {
        var policy = new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .Build();

        options.Filters.Add(new AuthorizeFilter(policy));
    })
    .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    services.ConfigureExternalCookie(options =>
    {
        // Other options
        options.Cookie.SameSite = SameSiteMode.None;
    });
    services.ConfigureApplicationCookie(options =>
    {
        options.Cookie.SameSite = SameSiteMode.None;
    });

    services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
     .AddAzureAD(options => Configuration.Bind("AzureAd", options))
     .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options => {
         options.Cookie.SameSite = SameSiteMode.None;
     });

}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    //app.UseCookiePolicy();
    app.UseCookiePolicy(new CookiePolicyOptions
    {
        MinimumSameSitePolicy = SameSiteMode.None,
    });
    app.UseAuthentication();
    app.UseMvc();
}

I added SameSiteMode.None in multiple areas. There are no changes in ios devices. This is a Razor Pages app with dotnet core 2.2 if that helps.

[Usan-Shrestha]

This worked for me for Azure Authentication on dotnet core 2.2.
Got this from @Tratcher and @thdotnet Conversation.

services.Configure<CookieAuthenticationOptions>(AzureADDefaults.CookieScheme, options =>
{
  options.Cookie.SameSite = SameSiteMode.None;
});

[ilatypov]

Before finding what "works for me", can I reproduce what did not work for anyone?

[Usan-Shrestha]

Before finding what "works for me", can I reproduce what did not work for anyone?

I created a new .net core 2.2 Razor Pages Web Application from Visual Studio 2017 with organizational authentication (work or school accounts) through Azure AD. After the site was published with IIS, on ios devices it would prompt users to login to the application but loop infinitely once credentials were entered. Solution from @blowdart did not fix the issue. Once I set AzureADDefaults CookieScheme to none, it has not hit that loop again.

[superdevguy]

I see this issue is still open, was any fix every implemented or are we just supposed to remove all of the security protection associated with SameSite cookie mode? I find it hard to believe that this is the only solution available. If it is, it's quite disappointing that we need to apply this insecure workaround and rely on anti forgery CSRF checks. Not to say that it isn't important to also implement those checks. Just sad to see that only a workaround was found and no action is being taken aside from that.

[Tratcher]

iOS's non-conformant implementation has significantly undermined the usefulness of the SameSite standard. There have been a few proposed mitigations for AspNetCore but we don't have any concrete plans at this time.

[ilatypov]

To this day I did not see a test or a sample project that clearly demonstrates a reproducible failure. I noticed that humans tend to enter heated debates when complexity of issues increases.

[minhhieugma]

This worked for me for Azure Authentication on dotnet core 2.2.
Got this from @Tratcher and @thdotnet Conversation.

services.Configure<CookieAuthenticationOptions>(AzureADDefaults.CookieScheme, options =>
{
  options.Cookie.SameSite = SameSiteMode.None;
});

Above code works for me as well. Thank guys all. You save my life!

These code bring me to another issue

options.ResponseType = "code";
options.ResponseMode = "query";

[blowdart]

As same site is now going to be broken by google in other ways, closing, and a new discussion issue will open when the support for the Chrome same-site updates arrives.