Bug #90890
closed
Default SameSite cookie setting breaks payments
0%
Description
The new default setting used by the SameSite cookie implementation (8.7.31, 9.5.14, etc.) for the frontend (SameSite=lax) breaks every TYPO3 site with a shop using an external payment provider (i.e. almost all). Due to this setting, the browser doesn't send the TYPO3 FE cookie any more to the TYPO3 site when the payment gateway redirects the browser to the TYPO3 site again after the payment. Then, there's no session any more and the payment status can't be updated.
Breaking essential functionality must not happen within a minor release and thus, we would highly recommend to use SameSite=none as default value, at least for 8.7.x and 9.5.x
Updated by Oliver Hader over 4 years ago
- Status changed from New to Needs Feedback
Thanks for your report.
SameSite cookie handling is evaluated as "lax" when no explicit values are defined since recent Google Chrome releases (see https://chromestatus.com/feature/5088147346030592).
Thus, without the changes of issue #90351 (see https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/8.7.x/Feature-90351-ConfigureTYPO3-shippedCookiesWithSameSiteFlag.html) your sites would have been broken without any involvement of TYPO3 at all - since they would have been used "lax" per default. With the feature introduce recently in TYPO3 users now have the possibility to adjust the SameSite cookie setting.
In order to mitigate cross-site request forgery (as a potential security vulnerability) and address data-privacy concerns, we at least suggest to use "lax" (as mentioned, Google Chrome default as well) - however "strict" would be the desired way to go here.
Could you please provide more insight into the whole HTTP request/response sequences in your use case and which services are issuing or consuming which kind of cookie? Having (obfuscated) domain names would be essential here when talking about "same site".
Thanks in advance for your feedback!
Updated by Oliver Hader over 4 years ago
- Related to Feature #90351: Allow TYPO3 to make SameSite cookies configurable added
Updated by Aimeos no-lastname-given over 4 years ago
Example:
1.) Customer puts a product into the basket at site myshop.com
2.) Customer selects credit card payment at myshop.com
3.) Customer is redirected to payment-gateway.com (no cookies sent -> OK)
4.) Customer enters credit card data at payment-gateway.com
5.) payment-gateway.com redirects the customer back to myshop.com (no TYPO3 FE cookie sent -> problem)
6.) Customers browser requests myshop.com/confirm/ without TYPO3 FE cookie
7.) TYPO3 of myshop.com cannot associate session with order reference to customer, payment update fails
Updated by Oliver Hader over 4 years ago
Steps 1-4 are not important for SameSite, the interesting part happens between step 5 and 6.
How is the user sent back to myshop.com, does that happen automatically with a redirect or within an iframe?
Basically what you described is plain SameSite vs. CrossSite request handling - independent from TYPO3 - like described in https://blog.heroku.com/chrome-changes-samesite-cookie#how-is-chrome-protecting-users-against-csrf-attacks
I've spotted a couple of shop vendors (Shopify et al) suggesting to set SameSite to none to work-around CrossSite scenarios.
In general:
- clicking a link on payment-gateway.com "back to shop" triggers a navigation event and should send SameSite cookie with the request
- receiving a HTTP redirect ("Location: https://myshop.com/confirm") should send SameSite cookie with request
- redirects triggered in an iframe or JavaScript (fetch API) are expected not to send SameSite cookies
Updated by Aimeos no-lastname-given over 4 years ago
Contrary to my previous thought, we've seen the problem only when using Datatrans (Swiss payment provider) up to now. But they don't do anything special and redirect to myshop.com just like others do. No iframe is used on mshop.com side and Chrome doesn't send the FE-User cookie when redirected to myshop.com and requesting the myshop.com order confirmation page (nothing special there too).
Updated by Simon Gilli over 4 years ago
- Status changed from Needs Feedback to Closed
This issue is more related to Google Chrome and perhaps Datatrans and the reporter agrees to close it for now.