Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Hi all,

I have a customer which has been using SuperOffice for almost 2 years now. They intensively use our Service solution and as part of that solution, I have added two web panels in SuperOffice Service which directly load data from their PrestaShop (see screenshot below) and tracking information via B2C. In order for this to work properly, the user needs to logon to PrestaShop and to B2C once in their webbrowser and after that, those credentials are used automatically to load the iFrames in the ticket web panels shown in the screenshot below.

With the latest release of Google Chrome, it appears that the usage of 3rd party cookies (which are used to make the solution described above possible) are no longer accepted by default. Instead, by default, these kind of 3rd party cookies are blocked (more info: https://headerbidding.co/chrome-samesite-cookie-update/).

In short - Chrome has introduced the following change in its latest release (v80), which means:

- Enforce Lax as the default value of the SameSite cookie. That means, if you manually don’t set the value for the SameSite cookies, it will be automatically set to Lax by default. Before, the value of the SameSite cookie was always set to None.

If I inspect the webpage of the ticket, I indeed get an error message which confirms why the web panels are no longer using the cookie information (credentials to access the content directly, in this case) which is similar to the message shown below:

Check SameSite cookies in Chrome

 

My question:

- Is this something that needs to be changed in the cookies of SuperOffice or should our customer contact PrestaShop and B2C to change their cookies to add the SameSite attribute and set it to None & Secure?

 

My workaround

If your customer is experiencing the same issue as described above, the current (short-term!) work-around would be:

1) Go to chrome://flags/

2) Use CTRL+F to find the text "SameSite"

3) Change the following two settings to Disabled: SameSite by default cookies & Cookies without SameSite must be secure

 

Awaiting your response whether this is SuperOffice-related, or if they should contact the other parties (PrestaShop and/or B2C).

 

RE: Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Hello Bas,

You will need to contact PrestaShop/B2C about this, they will need to mark their session cookies with the correct SameSite attribute to allow the session cookies to be send through the iframe loaded from CS when loading their site.

Note: Allowing this is kind of a security risk so it could be they will not change it.

Av: David Hollegien 18. mar 2020

RE: Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Hi Bas,

This is caused by Chrome. All partners have to implement the changes in their application as SuperOffice cannot change the behavior of Chrome, so the customer should contact the third-party.

There has been some discussion about the technical aspects here: https://community.superoffice.com/en/developer/forum/rooms/topic/superoffice-product-api-group/crm-online-application/how-does-chrome-blocking-third-party-cookies-affect-us/

Av: Matthijs Wagemakers 19. mar 2020

RE: Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Thank you both for the quick response. It confirms my thought that this is something that the 3rd party should/could change. I was in doubt whether it is related to our cookies or to the cookies of the other party.

By the way, I suppose the work-around mentioned in the article below would be a better alternative, since my work-around mentioned above is applied to all websites?

========

Alternatively, you can leave “Block third-party cookies and site data” enabled and add cloudHQ.net and google.com in the Allow list:

 

  1. [*.]google.com
  2. [*.]cloudhq.net

chrome extension

Source: https://support.cloudhq.net/how-to-enable-3rd-party-cookies-in-google-chrome-browser/

Av: Bas Kreijveld 19. mar 2020

RE: Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Hi everyone,

I'm new to the forum.  I'm from CustomerGauge which is one of the partner applications that is accessed from SuperOffice via an iFrame.   I spotted this thread addressed my question exactly.  So I hope me re-opening an old one is better etiquette than creating a duplicate....

So, my question isn't about the mechanics of how to workaround the new samesite default browser settings.  It is more about the security risk of whether it is a good idea to do so.

Our understanding is that setting 'samesite = none & secure', (either from our partner application, or by the user changing browser settings) (re)introduces a data security risk.  i.e. It allows browser pages, other than the SuperOffice host application, to access the partner application's cookies, including login session cookies.  Thus a malicious page running in a SuperOffice user's browser could call the partner application's APIs, using its open session, in order to try and access customer data.    Do other partners have the same concern?

I did hear a good suggestion that the threat could be mitigated by the partner application only conditionally setting samesite=none and X-frame-options.  i.e. when the referrer is SuperOffice.com.  But isn't 'Referrer Spoofing' relatively easy for a malicious page to implement?

So my question is, have I misunderstood the implications of disabling samesite cookie protection or have I understood them ok but am overestimating the risk?

 

 

Av: Antony Laycock 13. okt 2020

RE: Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Hi Antony,

Unfortunately I am not an expert in this topic, but maybe I can give some kind of inspiration.

One of my customers also was struggling with this topic and they used the following method to solve the issue:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

 

The string they added was the following header:

Content-Security-Policy: frame-ancestors https://online.superoffice.com https://online2.superoffice.com;

 

From what I understand, by adding such a header, you disable the possibility of other websites using your content (e.g. via an iFrame), but you allow specific websites (in this case, superoffice.com) to access your content.

Av: Bas Kreijveld 13. okt 2020

RE: Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Do note that we now also have online3.superoffice.com.
To find your current public endpoint, go to: https://online.superoffice.com/api/state/custXXXX - replace XXXX with your customer id / CustID

We make no guarantees that the public endpoint you are located on now will never change.
Read more here

 

Av: Margrethe Romnes 14. okt 2020

RE: Issue with Service Web Panels - 3rd party cookies in latest Google Chrome release are blocked by default

Hi Margrethe,

 

Thank you for the useful info. I suppose using a wildcard could solve that "issue":

 

Content-Security-Policy: frame-ancestors https://online.superoffice.com https://online2.superoffice.com;

will then be:

Content-Security-Policy: frame-ancestors https://*.superoffice.com;

Av: Bas Kreijveld 26. okt 2020