14 DAY TRIAL // Hungarian security expert Gabor Szathmari has analyzed the login pages of 21 major US banks and found that 9 load third-party JavasCript assets, exposing users to unnecessary dangers.
Theoretically, bank login pages should be the safest places on the Internet. In practice, they are far from being so, and there are multiple reasons this happens.
As Mr. Szathmari has discovered in his research, some US banks fail to protect this page and unwittingly load JavaScript resources from third-party sites.
But loading JavaScript files is not a problem, since websites need JavaScript files to work properly these days. The danger relies in the fact that some of these files are stored on another company's server.
Hackers should focus on compromising third-party analytics services
If that company gets compromised, attackers could very well alter these third-party scripts and deliver malicious code, which is executed right on the bank's login page.
And the danger is real because something like this has already happened in the past. SilverPop, one of the companies whose scripts are loaded on the login page of BT&T, a US bank, was hacked in 2010.
In that incident, hackers only compromised its email automation software. Imagine if this incident repeated today. Do you think the hackers would go after their email software, or would try to compromise the JavaScript code loaded on bank login pages?
The answer is simple because Web-based exploits have become more prevalent in recent years. Thanks to many new HTML5 APIs, malicious JavaScript code now allows you to log keystrokes, steal data entered in forms, take screengrabs, steal browser cookies, and even communicate with Flash to exploit many of its security loopholes.
Third-party analytics services are a backdoor left wide open
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, thanks to their analytics provider.
As Mr. Szathmari explains, the solution is quite simple. Removing analytics code from these pages is the quickest way to neutralize the threat. Additionally, implementing Subresource Integrity (SRI) is also 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 that 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. In case the third-party was compromised, SRI will block rogue resources from executing in the browser.
Mr. Szathmari is also the man behind SRItest.io, a website where users can scan websites for Subresource Integrity (SRI) cryptographic hashes.
