Please raise with
Metro Bank were warned they had no control of their use of Polyfill in 2023.
In 2024 Polyfill systems started to hack users on websites that adopted it.
Around the same time Metro Bank quietly removed if from their site, did they remove it in time?
(sonatype.com) Polyfill.io supply chain attack hits 100,000+ websites - all you need to know
When you use online banking, most banks give others your access too.
For centuries, bank staff have access, but we expect security.
Provided by processes, monitoring and signed paper trails.
When challenged, we expect banks can prove whether you asked for what staff did.
But not online.
That moment in Mr Bates vs The Post Office, when they discover Fujitsu had remote access as subpostmasters
That is the nature of problem here.
In this case, remote access means others can make the web page you are looking at, do what they like and without it showing on the page.
Your browser downloads these banks' web pages.
The banks' page will include bank code that runs in the web page... no surprise there.
But the surprise is, that often, bank code, then tries to download further code, directly from other companies websites, into the the banking page you are using.
Websites they cannot monitor, do not own and do not control and this further code can do whatever it likes in the online banking page.
Perhaps: read login details, fake login forms to grab passwords, fill out forms, click buttons, return data to those websites, send their choice of data to bank servers or take users to malicious websites.
By sharing access to login credentials or capabilities for faking login forms, the banks no longer can differentiate between what a customer or one of their chosen third party's does.
By allowing arbitrary code to load from the third parties, the banks can no longer differentiate actions in your web browser to those of a third party they gave access to.
Nobody should be able to use your logged in account, this is likely a critical security breach.
If you hand your passwords to others, you will be held negligent for any damage that results.
But what if the system you use, just gives another your access?
What you may not know is that it is common for websites to give others remote access to act as you on their webpages, access to your user account.
Worse, in many cases access includes to credentials, thus risking continued access at any time.
If access is abused, any logs are likely to indicate the activity was by the legitimate user, much like the poor sub-postmasters.
The UK regulator responsible in this domain, the ICO, were themselves hacked by this vulnerability in 2018, resulting in visitors to the ICO website having their devices hijacked to mine cryptocurrency.
Had the attackers been more aggressive, they could have captured data from whistleblowers, industry data breach reports and the public's complaints (the ICO got lucky) - or at least we think they did, the ICO servers have no logs of what the attackers actually did.
Despite being hacked, the ICO have failed to enforce data protection law and stop this vulnerability.
In one famous instance a third party accidentally hoovered up users passwords, personal identifiers and more.
This incident is not alone and the capturing of sensitive data, including credit card details has happened by accident on other sites too.
When companies just install some of these integrations to their website it can result in significant data breaches regardless of remote access being attempted.
Access depends on a site loading third parties' web apps
Apps loaded directly not from the servers of the website you have trusted, but from a third parties' server that they have delegate control to.
Those apps have remote access within these pages and this has been validated by tests to check for capabilities.
The following capabilities were checked and if any failed it resulted in their appearance here.:
A significant failure here is the lack of use of the Subresource Integrity feature.
Whilst far from providing complete security for third parties it does significantly limit what they can do and offers a starting point for protecting against remote access.
This combined with ensuring the application doesn't evaluate any JavaScript itself (uses eval or similar functions) can lock down remote access risks. However, it will be a minefield as the site has to ensure it maintains any safeguards at all times when using third parties. The default security model in the web is to give third party JavaScript remote access.
This nature of remote access is often technically known as remote code execution.
The code offered by a server can be modified by whoever controls the server or whoever can control which server the domain points to.