Bank login pages should be the safest places on the Internet, however, it turns out they are far from being so, and there are numerous reasons this happens.
According to a research by Gabor Szathmari, some US banks are not able to protect their login pages and accidentally load JavaScript resources from third-party websites.
However, loading JavaScript files is not a problem, as websites need JavaScript files to work properly. The real danger relies in the fact that some of these files are stored on another company’s server, which is very risky.
If a company gets compromised, hackers could very well alter these third-party scripts and deliver malicious code, which is executed right on the bank’s login page. In this case the danger is real because something like this has already happened in the past.
In 2010, SilverPop, one of the companies whose scripts are loaded on the login page of BT&T, was hacked. At that time hackers only compromised its email automation software, however, if it is nowadays, they would certainly log keystrokes, steal data entered in forms, take screengrabs, steal browser cookies, and even communicate with Flash to exploit many of its security loopholes.
In fact, just a simple analytics script can break down a bank’s complex security policy. No matter how many multi-million dollar deals banks sign with cyber-security vendors, by continuing to allow third-party analytics code to load on login pages, or even the user’s banking dashboard, banks are leaving a backdoor wide open to attacks, because of their analytics provider.
According to Mr. Szathmari, the solution is simple. Removing analytics code from these pages is the fastest way to neutralize the threat. Also, implementing Subresource Integrity (SRI) is another way to allow these scripts to load but remain safe in case the third-party service gets compromised.
Despite not being supported in all browsers, W3C’s new SRI specification is already the darling of many security experts. GitHub has even gone forward and implemented it on its website.
A browser which interprets a page’s code where SRI has been implemented will be able to tell if the third-party asset was compromised or altered. SRI does this by using cryptographic digests to analyze the JS or CSS it received from a third-party to an expected content payload. If the third-party was compromised, SRI will block rogue resources from executing in the browser.
