Project background and problem location

Project background

Website A (assume SameSite.a.com) is embedded as iframe in website B (assume http://test.a.com…

Problem orientation

  • Preliminary analysis shows that website A is A third-party page. If website A is opened externally, it can be accessed separately to eliminate the problems of website A
  • Change the browser, in Firefox and Edge, website A can normally load in iframe. The initial diagnosis is a browser compatibility problem
  • Compare the versions of Chrome that don’t load properly with those that load properly, both updated to the latest version 89. Found that the state has not changed, can still load, can not still load. (Because of this phenomenon, there are doubts about whether there is a browser version compatibility issue)
  • When you open the browser console, an interface request error occurs, and the console displays the following message

The error is related to the SameSite property, so look up the SameSite problem. Related attributes of SameSite can be refer to Ruan Yifeng’sThe SameSite property of the Cookie”

The cause of the problem

Google will be released in February 2020, no. 4 of the Chrome version 80 (schedule:www.chromestatus.com/features/sc… Cookie, the default for all cookies add SameSite = Lax property (www.chromestatus.com/feature/508)… , and reject the Secure Cookie is set to SameSite = None (www.chromestatus.com/feature/563)… This is to block CSRF vulnerabilities at source

The following scenarios are affected in Chrome80:

  • Component data is API requests based on third-party logins
  • HTTP local deployment

The solution

Current project environment: The main domain name of website A is the same as that of website B. The domain name of website A is HTTPS. If this doesn’t work, consider the environment first

Updated on 2021/6/9: The following solution is only available for version 80. After version 90 is updated, scheme 1 is invalid and you cannot manually set the value of SameSite. The initial suspicion at the end of the paper has also failed. The best solution is to upgrade to HTTPS and keep the domain names the same

Matters needing attention:

  • SameSite=None Needs to be set only for chrome80 and older because Chrome51-Chrome66 and some other browsers don’t accept SameSite=None
  • If HTTP and HTTPS are used at the same time, you need to enable Secure only when HTTPS is used. SameSite = None. The reason for this is that when Secure is set to true, the created Cookie is sent to the server in a Secure manner, that is, it can only be sent by the browser to the server for session authentication in an HTTPS connection.
  • As described in the Google Reject Insecure SameSite=None Cookies, the “Reject cookies for insecure SameSite=None” feature is enabled by default after version 85, with an explicit declaration secure=true, This cookie can only be carried across domains.

The solution

    1. Open tabs in Chrome and enter the following two links to set the graphical configuration to Disabled. (The test is effective and can be used as an emergency solution. After the configuration is updated, the browser must be restarted to take effect.)
chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure
Copy the code

    1. Use Firefox or Edge (valid) or downgrade Chrome to version 79 or below and turn off automatic updates (untested, not recommended personally, poor user experience)
    1. Deploy the two systems on the same server and send cookies using the same IP origin policy. (Not tested)
    1. Purchase an SSL certificate, upgrade the HTTP service, switch the API to HTTPS requests, and check whether the set-cookie in the response header contains SameSite=None and Secure (after 85, Secure=true is explicitly Set).

conclusion

  • Although the problem was fixed, it was the browser version, but it is not clear why some computers load correctly and others don’t
  • Solution 4 was used to solve the problem, but I still found the final solution after stepping on a lot of holes when browsing the blog.

Here is a brief introduction to the actual solution of scheme 4:

  1. If the cookie required by the front end is stored in the browser directly by the back end through set-cookie, then the back end is required in theresponseThe response header sets the property. Each required cookie must be set once. If the cookie is not set, a yellow icon appears (to remind you that the cookie was not set successfully), which is unreadable
response.setHeader(name: "Set-Cookie", value: "_u=xxxx; Path=/Login; SameSite=None; Secure=true")
Copy the code

  1. You can also set it in Nginx to automatically add these two attributes to cookies (it is not safe to set this for all cookies, it is not recommended to use this method, only for certain required cookies).
Proxy_cookie_path/"/; httponly; Secure=true; SameSite=None";Copy the code
  1. The first method is only applicable to cookies set by the back-end. In the problem encountered this time, cookies are saved in the browser after the front-end gets the data returned by the back-end, so the problem cannot be solved by using the first method. If the front end stores the cookie in the browser, it only needs to write the following code to set the corresponding cookie properties, thus solving the problem
Cookies.set("Admin-Token", res.token); document.cookie = "Admin-Token=" + res.token + "; SameSite=None; Secure=true";Copy the code

Refer to the article

Ruan Yifeng: “SameSite Properties of Cookies” on the possible impact of Chrome (Google browser) upgrading to post-80s and the SameSite strategy of the solution browser The SameSite problem with the Cross-domain Cookie of Chrome causes an exception in accessing the embedded iframe page