Five Client-Side Web Application Risks Banks and Investments Should Be Aware of


Can you name the main cybersecurity risks for banks and investments? Most would likely list cyberattacks such as phishing, credential theft, DDoS attacks, and possibly ransomware. But would you be surprised to learn that there is something on the list that many in the banking and investment industry overlook, namely client-side cybersecurity threats. You know the kind… jQuery related ones, cross-site scripting (XSS), JavaScript Injections, formjackingetc Here are five notable client-side web application risks that banking and financial services organizations should be aware of.

#1—JavaScript supply chain and open-source repositories

Cybersecurity news features more and more articles on JavaScript supply chain issues. Recent malware issues discovered in NPM packages are a good example. NPM serves as an open-source repository for JavaScript developers to share, copy, and reuse snippets of code for building web applications. Supply chain threats arise when repository code is corrupted, intentionally or unintentionally. A recent study found thousands of malicious packages, 14% of which were designed to steal information such as credentials, and 82% performed reconnaissance by passively or actively collecting information for targeting future attacks.

DevOps Connect: DevSecOps @ RSAC 2022

Repositories such as NPM attract criminals for a variety of reasons:

  • NPM, in particular, is one of the most popular repositories, with over 1.8 million active packages.
  • Package repositories and registries contain more than just code snippets. They also store metadata of installation packages and configurations, i.e. all attack vectors. Criminals know that it is difficult for IT to manually examine each package for version control and malicious intent. That is why automated client-side crawls because dangerous scripts are so important.

#2—JavaScript and jQuery supply chain

Too many web applications are still running under massive technology debt tied to legacy jQuery code. (A 2019 study estimated that over 70% of websites analyzed used jQuery.) In fact, jQuery has become somewhat infamous for the number of vulnerabilities it contains. Most of these vulnerabilities are in early versions of jQuery (e.g., jQuery 1.x) and relate to cross-site scripting, although other types of vulnerabilities, such as prototype pollution and denial of service, are also present.

Web applications also use jQuery libraries to extend capabilities, which increases the risk of attack. Some jQuery-specific libraries are actually malicious versions of open source libraries. Additionally, despite repeated alerts about malicious content in a number of jQuery libraries, these libraries continue to maintain and distribute malicious scripts without any remediation or update plans.

#3—Open client-side redirect attacks

Banks and investment firms with login pages are particularly susceptible to open client-side redirect attacks, as many of them use third-party vendors as their primary login portal. In this type of attack, hackers use client-side JavaScript to spoof a redirect URL (a URL that redirects from the company’s main website to a banking customer login page), sending customers to a malicious site at the place. This type of attack also has notable implications for the current and upcoming PCI DSS 3.x standard. PCI-DSS 4.0 Compliancesince credit card issuing banks have to comply with requirements.

#4—Outdated and ineffective client-side protection

Traditional perimeter security tools do not secure the client side, and tools such as web application firewalls (WAFs), policy controls and threat intelligence are only partially effective for client side protection . In the case of WAFs, they are only designed to protect the services that user-facing web applications apply to collect, store and use data. WAFs are not designed to protect the browser-level UI itself, which means they are unable to detect and protect against sophisticated skimming malware, drive-by skimming , supply chain attacks, or sideloading and chainloading attacks. Policy controls require extensive manual support, unless you have a automated solution. And, while threat intelligence can tell you about existing threats, intelligence feeds won’t remediate those threats for you.

#5—Unsafe JavaScript

JavaScript is the most commonly used web application scripting language. it is estimated that 98% of websites in the world use JavaScript. But JavaScript was never built with security in mind. Without security permissions built into the JS language, it is difficult to prevent client-side attacks on JavaScript code. The most common JavaScript security vulnerabilities include:

  • Source code vulnerabilities
  • Using client-side validation
  • Unintentional script execution
  • Exposure of session data
  • Unintentional user activity

What is the risk impact of client-side web applications on banking and investing?

A data breach and the loss of sensitive customer information, including bank account numbers, personally identifiable information (PII), and identifying information can have a lasting impact beyond the simple disruption of business, damage to reputation and loss of profits. Foremost among these concerns are regulatory and compliance penalties. Government and financial industry cybersecurity regulations and mandates, such as those of the Security and Exchange Commission (SEC), Gramm-Leach-Bliley Act (GLBA) Backup rulethe General Data Protection Regulation (GDPR)and the Payment Card Industry Data Security Standards (PCI DSS)can subject companies to fines and trade restrictions for data breaches or privacy breaches.

Client-Side Web Application Protection Solutions for Banking and Investment

First and foremost, cybersecurity professionals working for financial institutions or investment firms should have a process in place to ensure the use and maintenance of secure JavaScript repositories. Banking and investment entities should also ensure that they are using the latest JavaScript code and are not increasing the risk of breaches through legacy code, such as older jQuery. To identify potential risk areas, the bank and the investment should perform automated client-side attack surface monitoring using an automated solution specifically designed to explore systems and identify malicious script activity on existing web applications. In addition, industry security professionals should familiarize themselves with the OWASP Top Ten Client-Side Security Risks. Security professionals can use these new OWASP risks to improve client-side web application protection.

The post office Five Client-Side Web Application Risks Banks and Investments Should Be Aware of appeared first on Feracin.

*** This is a syndicated blog from the Security Bloggers Network of Feracin Written by Feroot Security Team. Read the original post at:


About Author

Comments are closed.