View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007768 | OXID eShop (all versions) | 4.02. Session handling | public | 2025-02-07 16:20 | 2025-02-12 15:28 |
| Reporter | mario_lorenz | Assigned To | |||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | 6.5.0 | ||||
| Summary | 0007768: Cookie-Attribute "samesite" = none + secure = true als Standard für Payment-Module benötigt | ||||
| Description | Beim Testen der Payment-Module mit dem Chrome-Browser ist aufgefallen, das unsere Cookies nach der Rückleitung vom Payment-Gateway nicht mehr vorhanden sind. Dadurch kann die Session nicht wieder aufgenommen werden. Der sToken-Hash reicht nicht aus, um die Session wieder herzustellen, da OXID nicht nur die "sid" braucht, sondern auch den Cookie "sid_key". Warum klappt das in Chrome nicht mehr? Seit Chrome Version 80 (Release 4. Februar 2020) nutzt Chrome das Cookie-Attribute "SameSite". Damit eine Weiterleitung zum Payment-Gateway hin und vom Gateway wieder zurück erfolgen kann, braucht es unsere Cookies mit dem Attribute "SameSite" = "none" und Explizit als "secure". Secure darf bei Verwendung des Attributes "SameSite" = "none" nicht false sein. When testing the payment modules with the Chrome browser, we noticed that our cookies are no longer present after the return from the payment gateway. This means that the session cannot be resumed. The sToken hash is not sufficient to restore the session because OXID needs not only the "sid" but also the cookie "sid_key". Why doesn't this work in Chrome anymore? Since Chrome version 80 (release February 4, 2020), Chrome has used the cookie attribute "SameSite". In order to be able to redirect to the payment gateway and back from the gateway, our cookies with the attribute "SameSite" = "none" and explicitly as "secure" are required. Secure must be true (in anycase) when using the attribute "SameSite" = "none". | ||||
| Steps To Reproduce | Setup: OXID 7.1 + TeleCash-Module v1.0.0-rc2 + Chrome >= v80 Then try to pay with the test data | ||||
| Additional Information | The problem in our code in the class UtilsServer.php, method setOxCookie is how we set cookies. We still use the style of PHP <=7.2. Only since PHP7.3 has it been possible to pass attributes. So that I can successfully make the payment, I have built in the following hack before the call "return setcookie". if (PHP_VERSION_ID >= 70300) { return setcookie( $sName, $sValue, [ 'expires' => $iExpire, 'path' => $this->getCookiePath($sPath), 'domain' => $this->getCookieDomain($sDomain), 'secure' => true, 'httponly' => $blHttpOnly, 'samesite' => 'None' ] ); } This enables the return from the payment gateway back to the shop. I think the problem is very important and I think a port for all OXID versions from version 6 onwards is necessary, because browser technology, unlike shop development, does not stand still at the merchant. It is only a matter of time before it no longer works in Firefox either. | ||||
| Tags | No tags attached. | ||||
| Theme | Not defined | ||||
| Browser | Google Chrome | ||||
| PHP Version | 7.3 | ||||
| Database Version | Not defined | ||||
|
|
Mario created a ticket for TeleCash and is currently working on the solution. I updated the ticket status. @Mario Could you verify again if this issue is only found with the telecash module and not found in other modules? The descriptions seems to be general, where as the Module for the bug ticket is only set to TeleCash. |
|
|
@Mark.Schuette: It was correctly examined for the first time in the TeleCash module. In principle, all payment modules that redirect to a payment gateway during checkout and then return to the shop from there are affected. When returning, the solutions that still pass data to the shop via POST request are particularly vulnerable. After consultation with the core team, there is the following "quick" solution by adjusting the htaccess: <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;Secure" </If> The condition in the entry is so complicated that some Apple devices have problems with the following entry alone in the htaccess: Header always edit Set-Cookie (.*) "$1; SameSite=None;Secure" During the brainstorming, the idea arose that cookie handling could also be solved in the form of modules. For OXID >=7.3 as part of the security module. FOR OXID <=7.2 as part of a hotfix module. However, further steps still need to be examined in more detail. |
|
|
@michael_keiluweit: In the next step, our core team will discuss our current solution with you regarding security aspects. |
|
|
More Informations about the htaccess-Solution: https://webmasters.stackexchange.com/questions/128635/chrome-80-clears-session-cookies-for-users-returning-from-payment-gateway By the way: Firefox also warns in the developer tools that cookies without SameSite attributes will no longer be handled correctly. |
|
|
I have created corresponding bug tickets for hotfixes in all of our payment modules. QA will have to assess if the bug is apparent in other modules as well. Every Module will be inspected as it is suspected to be a general issue. Thanks for suggesting a solution @mario_lorenz. |
