In this post, I’m going to try to tell (as simple as possible) the new update about cookie access policy and it’s affects on some Fin-Tech process.
You can also skip to how to fix same site issue post.
At Early October, 2019 the Google Chromium Project announced that the new versions of the Chromium Project based browsers are starting to change their behavior/policy on Cookies security while accessing from different domains. The updates were scheduled as a smooth transition extending over time with increasing percentages of updated browsers. By the time of this post Google updated more than 50% of them.
That update simply means, if a web app is accessing (sending requests like XHR) to another domain, the browser is going to block the cookies of the target domain as default behavior. Google aims the target domain should be able to specify a list of domain can access and prevent security issues within the update.
The full details are here.
So the first question of this blog “Was that a security vulnerability ?”
Sure, yes. The browser based technologies were able to send request to other websites while the client browsing another and unaware.
For example, this page could send a request from your browser to the twitter url (imitate you’re visiting that) and probably could access your twitter page if you logged in twitter. Even worse that request could be a HTTP POST request and publish a tweet.
Of course above example is not possible for the twitter due to the twitter already made provision against that. But there are billions of unaware websites and apps. Some web applications are stunning examples like the banking apps, e-commerce websites, web services of governments e.t.c.
The next question is “Is that Google’s job to fix security of websites ?”
I’m not sure that the Google has a responsibility nor is an authority nor a regulator of web security. In addition, I could not say that that vulnerability was a result of a browser security hole so can be fixed by a browser update.
The most important point is, this was not the only way. It seems, not the best way too while many of web apps should keep to be accessible by public. The webmasters and web developers were able to put precautions to their apps and handle their own accessing policy with simple and standard tools/codes. Most of them already did that. If think that it saved the of webmasters times anyway: unfortunately millions of them is now facing with issues of chrome based browsers.
Effects on Fin-Tech processes:
Since some banking services like 3D-Secure payment gateways have to be accessible from everywhere and have to use Javascript triggers on HTTP POST request to redirect validations steps, most of them started to get errors, feed backs from failed customers. Currently I do not have clear statistics but i have a hunch that between 10% and 20% of transactions has been failed and lost.
The previous week I noticed one of the key player PF company is not working at the payment validation step with my favorite browser but working on a different one. I can’t bet that they know that they have an issue. Because the request are redirecting to the login page and probably the log files doesn’t have signs about what happened at the previous page that I came from.
As far as I know the Turkish payment providers has already started to fix their authorization endpoints and gateways to be compatible with new rules for more than a year. But at least 30% of them are still having difficulties.
Since the SanalposPRO (one of my startups) is a self hosted opensource software, has published new versions with an additional rule set to try to find best fix depending on the different merchant infrastructures.