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.
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
#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.
- 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
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: https://www.feroot.com/blog/five-client-side-web-app-risks-banking-investment-should-know/