Chrome 80 clears session cookies for users returning from payment gateway

Question

I'm managing several e-commerce websites, they are all custom build and they all accept credit card payments via bank redirection (website redirects the client to bank's payment page, bank redirects client back to site after payment has been processed).

Once Chrome 80 was released, I noticed a common trend among all e-commerce websites, when the user has paid and is redirected from the bank back to the e-commerce site, all session cookies are missing. Thus the client is not recognized as the client who initiated the payment.

I'll try to illustrate the problem:

• example.tld - user receives a session cookie
• example.tld - user logs in with a valid email address
• example.tld - user places order
• example.tld - redirect user to mybank.tld
• mybank.tld - user enter cc details, payment is successful
• mybank.tld - redirect user to example.tld
• example.tld - unknown user, no cookies! redirect user to error page

This problem ONLY happens with Chrome 80, all other browsers work fine (Firefox, Safari, Edge, mobile browsers like Samsung Internet, etc). Older versions of Chrome also work fine (<=79).

This problem happens in ALL the e-commerce websites that I manage, the only consistent thing between them is Chrome 80.

Of course all e-commerce sites are PCI certified, use TLSv1.2 and the session cookie is defined with "domain", "secure" (true) and "httpOnly" (true) parameters set. Expires is set to "Session".

Is this some kind of new security feature that clears all current sessions/cookies when Chrome detects visits to a bank?

PS: my issue is not related to the SameSite problems others have, because I am not using crosssite scripting, iframes or anything like that.

Solution

At first glance the problem does not appear related to SameSite restrictions in the new Chrome v80. Apparently, that is exactly what causes the problem.

When the user is in the bank payment portal and has successfully paid, he is redirected back to the ecommerce site by a POST request to the "ok" URL. This POST request is seen as a crosssite request, thus Chrome removes the session cookies.

bank portal -> POST request -> ecommerce = lost cookies

The only solution is to enforce SameSite=None for all Chrom[e|ium] based browsers OR for all browsers except iOS/iPhone pre v13.

Note the bold "OR" in the above sentence. If you decide to set SameSite=None, you will brake some iOS/iPhone devices due to an Apple bug that incorrectly thinks that None is Strict.

A quick and dirty solution for Apache, is to use the following htaccess rule:

Header always edit Set-Cookie (.*) "$1; SameSite=None"

At the bottom of the [apple bug report] there is a more complete htaccess rule that avoids incompatible apple devices:

<If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-2]|iPad; CPU OS 1[0-2]|iPod touch; CPU iPhone OS 1[0-2]|Macintosh; Intel Mac OS X.*Version\x2F1[0-2].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
    Header always edit Set-Cookie (.*) "$1; SameSite=None"
</If>

In the two htaccess rules above, there is one important detail that I need to mention. SameSite=None only works with Secure cookies. If your cookie already sets Secure then no further steps need to be taken. If your cookies don't set Secure, then you need to append it to the above rules: SameSite=None;Secure

More details here:

• [caniuse details] https://caniuse.com/#search=samesite
• [apple bug report] https://bugs.webkit.org/show_bug.cgi?id=198181
• [chromium faq] https://www.chromium.org/updates/same-site/faq

Comments

[Stephen Ostermiller]

Would it be possible to give the bank a return URL that includes a session token in the URL itself rather than relying on cookies?

[Jimba]

Unfortunately that is not possible for two reasons. The bank does not allow us to add anything to the two return URLs, one is /bank-success/ and the other is /bank-fail/. The second problem is with the bank POST request to /bank-success/, we may add an order ID only, which is not enough to be a session ID and would also lower overall security.

[Stephen Ostermiller]

I'm not sure I completely understand. Is this a correct interpretation? Chrome 80 has a new cookie policy. In addition to not allowing cookies to be set for 3rd-party requests, it also doesn't send any 1st-party cookies for a 3rd-party request. Because the bank is triggering a POST request to your site, the request is treated as a 3rd-party request and cookies are not included with that request. You can get around this by marking your first-party cookies as "SameSite=None" such that they get sent back on all 3rd-party requests.

[Stephen Ostermiller]

Because the bank is using a POST request for the return URL, that request is being treated as a 3rd-party request and cookies are not sent. This is done to prevent cross site scripting and cross site forgery requests. See the table about half way down this page From Chrome's documentation it appears that they will send cookies if the checkout process at the bank takes less than 2 minutes (POST+LAX mitigation). Another workaround could be to have the bank use a GET request.

[Stephen Ostermiller]

Couldn't you also get around this by forcing the user to click again? If somebody comes back from the bank and doesn't have a session cookie, couldn't you have a link that says "click here"? When the user clicks it, the request would be a first-party request and the cookies would magically re-appear.

[Jimba]

Chrome's mistake, is that my session cookie was NOT set by the bank or a 3rd party, its set by the ecommerce application (1st-party cookie). But Chrome intervenes and removes it when the user makes the POST request. It would be more logical to block NEW cookies, not existing 1st-party cookies (so that the bank can't set its own session cookie for my econnerce sites). About the 2 minute POST+Lax mitigation, its not very solid, most elderly take 10+ minutes to pay. Unfortunately, our bank processor only supports POST because they submit an encrypted JSON object.

[Stephen Ostermiller]

Chrome prevents you from seeing the 1st-party cookie when a 3rd-party site sends a visitor to your site with a POST request. The cookie isn't "deleted," it just isn't sent with that particular request. This is intentionally done to prevent cross site forgery requests, it isn't a "mistake". But it will break your site unless you or your bank change something.

[Jimba]

It really does not matter what it does with the cookie, from the view of my application, there is no cookie when the user is redirected, thus he receives a new cookie and then taken to an error page. It is a mistake to delete or hide a cookie that I've set. I understand google being what they are, enforcing something that causes breakage because they are a monopoly. They should have kept the accepted system, if someone wanted this, they could set SameSite=Strict for their sites, not force everyone to set SameSite=None and break most Apple devices in the processes.

[Stephen Ostermiller]

Technically, this is the behavior of SameSite=Lax. Strict would hide cookies for any external referrer, not just for POST request from an external referrer.

[Sami.C]

The fact that the only option is a work-around to disable the option doesn't make a whole lot of sense. For those wanting to adopt the option, why should we have to disable it all together? There should be an option to white-list certain domains rather than just disable it all together. e.g. anyone who is using some form of payment gateway should be able to whitelist the payment gateway without compromising the entire system. Otherwise what's the point of the setting to begin with given everyone will need to turn it off :S

[user4540741]

I applied the htaccess fix as suggested by Apple but I am still getting the session logout issue after payment on the chrome browser.(i am using php 7.0.33)