New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
blowdart opened this Issue Sep 28, 2018 · 20 comments

Comments

Projects
None yet
@blowdart
Copy link
Member

blowdart commented Sep 28, 2018

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 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.

External Links

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

Revisions

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

@fabiano

This comment has been minimized.

Copy link

fabiano commented Sep 28, 2018

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

This comment has been minimized.

Copy link
Member

Tratcher commented Sep 28, 2018

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

@fabiano

This comment has been minimized.

Copy link

fabiano commented Sep 28, 2018

@Tratcher yes, you are right. Thanks.

@nicosabena

This comment has been minimized.

Copy link

nicosabena commented Oct 1, 2018

FYI this Webkit update also affects Safari on MacOS Mojave.

@rdellar

This comment has been minimized.

Copy link

rdellar commented Oct 3, 2018

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

This comment has been minimized.

Copy link
Member

Tratcher commented Oct 3, 2018

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

@conterio

This comment has been minimized.

Copy link

conterio commented Oct 4, 2018

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

@thdotnet

This comment has been minimized.

Copy link

thdotnet commented Nov 22, 2018

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

This comment has been minimized.

Copy link

lucachecchinasarva commented Nov 26, 2018

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

@thdotnet

This comment has been minimized.

Copy link

thdotnet commented Nov 26, 2018

@thdotnet

This comment has been minimized.

Copy link

thdotnet commented Nov 29, 2018

got help from @Tratcher

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

@Elruts

This comment has been minimized.

Copy link

Elruts commented Dec 11, 2018

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

This comment has been minimized.

Copy link
Member

Tratcher commented Dec 11, 2018

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

@Elruts

This comment has been minimized.

Copy link

Elruts commented Dec 12, 2018

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?
image

@Tratcher

This comment has been minimized.

Copy link
Member

Tratcher commented Dec 12, 2018

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

@Elruts

This comment has been minimized.

Copy link

Elruts commented Dec 12, 2018

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

@Tratcher

This comment has been minimized.

Copy link
Member

Tratcher commented Dec 12, 2018

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).

@aspnet-hello aspnet-hello transferred this issue from aspnet/Security Dec 13, 2018

@aspnet-hello aspnet-hello added this to the Discussions milestone Dec 13, 2018

@brockallen

This comment has been minimized.

Copy link

brockallen commented Jan 11, 2019

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

This comment has been minimized.

Copy link

ilatypov commented Jan 25, 2019

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

This comment has been minimized.

Copy link

gusgonnet commented Feb 20, 2019

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
image

Thank you,
Gustavo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment