Fusion SaaS Extension and Chrome 80 uptake
PS : Due to COVID19, Chrome has rolled back the behavior described in this blog, and the issue described here is no longer occurring, ‘FOR NOW’ .
But it still makes sense to be ready for it whenever Chrome and other browsers enable this behavior.
With the version 80 release of Google Chrome in Feb, the default behavior of the ‘SameSite’ flag in cookies has changed, which may break customers’ UI integration.
In this blog I’ll describe how this Chrome change affects Oracle Fusion Cloud customers. I will first explain the SameSite flag, followed by detailing the Chrome 80 behavior change. I will then describe what customers can do to prevent their Fusion SaaS UI integrations from breaking.
The SameSite flag
A browser cookie, to begin with, is a key value pair along with some attributes, and it is used to add persistent state to websites. For example, when a user logs on to myhcmsaas.com (or myerp,mycrm etc), the server may send the following Set-Cookie header in response :
Set-Cookie: jsessionid=<some random string>; Domain=myhcmsaas.com; Max-Age=86400;HttpOnly; Secure;
With the above cookie set, whenever the user accesses myhcmsaas.com (Domain) over https (Secure flag) and within one day of setting the cookie(Max-Age of 1 day in seconds), the browser sends the jsessionid value to the server as part of the request http header. The server can then use the jsessionid to validate the user.
Now, when a user visit myhcmsaas.com in her web browser, any cookies set by myhcmsaas.com are called first-party cookies, and all other cookies(set by, say advertisement images, iFrames, or sites in other browser tabs) are called third-party cookies.
Before SameSite was a thing, the browser didn’t distinguish between first-party and third-party requests, it blindly used to send the cookie as part of the request, as long as the Domain, Max-Age and other attributes matched.
This led to Cross-Site Resource Forgery(aka XSRF or CSRF) attacks, where a jealous adversary could present a naive user with a genuine-looking page(through email link, embedded iFrame etc), and assuming the user is logged into myhcmsaas.com(and hence has the cookie set) , could send a background request to terminate an employee on the naive user’s behalf. The browser would send the myhcmsaas cookies along with the request, and the server would validate the cookie and execute the request.
CSRF attacks can be prevented using dynamic nonces(outside the scope of this blog), but the SameSite cookie attribute(IETF draft) was introduced prevent these attacks. The attribute(now implemented by all browsers,) provided semantics on cookie usage as a third-party cookie.
The SameSite key has three possible values :
- None : No limitations and usage as a third-party cookie is allowed.
- Lax : Cannot be used as a third-party cookie.
- Strict : Stricter than Lax, URLs originating from external links not allowed as well.
So if the SameSite attribute is set to Lax/Strict, the jealous adversary won’t be able to execute the termination request, because the browser will treat myhcmsaas’s cookies as third-party cookies in that context, and it won’t send the authentication cookies along.
Get Ashish Singh’s stories in your inbox
Join Medium for free to get updates from this writer.
Let’s understand this with a more pertinent scenario. If myhcmsaas.com has a custom UI requirement, typically customers host the custom UI on some PaaS layer ( JCS for example), and the UI is iFramed into myhcmsaas.com. Assuming SSO was established between PaaS and SaaS, this provides a seamless user experience. But under the hood the PaaS UI has its own cookies belonging to its own domain, different from the SaaS server’s cookies.
So for the mycustompaas cookies(which are third-party in this context):
- If SameSite=None , those cookies will be sent as part of the request to mycustompaas servers, and things will work as expected
- If SameSite=Strict/Lax , those cookies won’t be sent as part of the request to mycustompaas servers. This will potentially break many scenarios, for example if the authentication cookies are not sent then mycustompaas will continue trying to authenticate the session indefinitely(manifested as redirect loop, multiple failed authentication attempts, etc).
However, what happens if the SameSite flag is not specified in the cookie ? This is very often the case if the PaaS/Web Developer does not provide SameSite flag in the cookies. The behavior then varies from browser to browser. So far most of the browsers defaulted SameSite flag being absent to the same behavior as SameSite=None.
But Google Chrome is the first browser to change this default starting version 80(released in Feb already), wherein the default behavior when the flag is absent is same as SameSite=Lax.
While this is a positive change and it provides better security, as we saw above it can potentially break UI Integration scenarios.
PS : Other web browsers will soon change to this new default behavior as well, Chrome just happens to be the first browser to enforce this.
Now that we understand the SameSite flag, if customers experience any problems related to SameSite(as seen Chrome Console or network logs) in their UI integration after upgrading to Chrome 80, they can take the following steps to remedy.
Solution
We can clearly see that the solution is to add a ‘SameSite=None’ flag in the cookies set by the mycustompaas servers, so that the default browser behavior is overridden.
Achieving this depends on the specific PaaS being used, but in general we can assume that any PaaS layer serving the webpage has some form of a Reverse Proxy before it.
For example Java Cloud Service has Oracle Traffic Director(OTD) in front acting as reverse proxy. Other PaaS layers may use Oracle HTTP Server as Reverse Proxy.
These reverse proxies are able to manipulate response headers, and form the ideal place to manipulate cookies and add the ‘SameSite=None’ in the Set-Cookie response header.
For example, with OTD, the following directive can be added in the .conf file to set the SameSite flag for all HttpOnly cookies when jsessionid is being set:
<If defined $cookie{‘JSESSIONID’}”>
Output fn=”sed-param-value” pblock=”srvhdrs” name=”set-cookie” sed=”s/HttpOnly/HttpOnly;Secure;SameSite=None/g”
</If>
The OTD Directives page provides more ways and options to construct such directives.
Similarly, in OHS, the following directive can be added to accomplish the same:
Header edit Set-Cookie ^(JSESSIONID.*)$ $1;SameSite=<your_value>;Secure
Similar directives are available for other reverse proxies including Nginx.
Once the directives are set and working properly, the user’s browser starts receiving the SameSite=None flag in the mycustompaas cookies, which then allows those cookies to be passed to requests going out to the iFramed mycustompaas page, hence bringing your UI integration back to normal!!
PS : This article is Chrome specific, but if the Fusion SaaS customers prefer other browsers(such as Safari), they just need to verify the SameSite semantics for the specific browser, and update the directives above accordingly.
References :
- https://support.oracle.com/epmos/faces/DocumentDisplay?id=2637652.1
- https://docs.oracle.com/middleware/12212/otd/cfrref/conditions.htm#OTCFR1235
- https://medium.com/compass-security/samesite-cookie-attribute-33b3bfeaeb95
- https://web.dev/samesite-cookies-explained/
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
