Client-Side

Today, web apps and pages load an average of more than 30 third-party scripts at runtime in the user’s browser. Naturally, the potential for compromise via that user’s device has been growing exponentially.

When you rely on third-party code integrated into the user experience almost in real time, you open the door to attack.

The organization that owns and operates the website the user is viewing does not control the code or have visibility into how it behaves at runtime. And with the rise of online shopping, as more transactions move online and more sensitive data traverses networks, the incentive and opportunities for client-side attacks grow.

Furthermore, client-side JavaScript is easy to target because anyone can debug the code and even modify it at runtime. This becomes problematic because companies often store important business logic on the client side, which is sometimes unavoidable due to the absence of a back end or the need to avoid performance losses.

Companies’ proprietary algorithms and logic end up running in an adversarial environment, which opens the door to a series of attacks, including automated abuse, piracy, intellectual property theft, and data exfiltration. Unfortunately, client-side attacks take longer to detect.

Given the risks of Magecart and web supply chain attacks, regulators have been pushing strict regulations to ensure businesses protect themselves and their sensitive data.

Client-side attacks occur when a malicious actor exploits security weaknesses or vulnerabilities on the end-user’s device, whether it is a mobile device, a browser, or another client application.

Because there’s so much sensitive data being handled on the client side nowadays, including personally identifiable information (PII), payment data, protected health information, etc., client-side attacks are considered one of the most dangerous types of security threats.

Because data handled on the client-side must be unencrypted, this also presents attackers with a window of opportunity to access and potentially leak this data before it is encrypted and sent over the network to be stored at a secure server.

Client-side attack examples

Relevant client-side attack examples include Magecart web skimming attacks, where malicious actors tamper with client-side payment forms to collect credit card information and send it to their own servers, and customer hijacking, where the user is diverted to another page.

The goal of these attacks is to steal valuable information from a webpage, computer, or server, especially sensitive data such as credit card numbers. Enterprises like British Airways and Ticketmaster are two of the thousands of victims.

Several key frameworks provide information on client-side vulnerabilities.

OWASP

One of the most popular frameworks is OWASP, the Open Web Application Security Project. It is a non-profit entity with international recognition, acting with a focus on collaboration to strengthen software security worldwide. OWASP maintains a list of the 10 most dangerous web application security flaws, along with effective methods for addressing them.

Cybersecurity Framework from NIST

The Cybersecurity Framework from the US National Institute of Standards and Technology (NIST) is also very well-known. Both of these frameworks highlight the importance of ensuring the integrity of both first- and third-party code running on the client-side of web applications.

Regulatory requirements

In addition to these guidelines, regulatory requirements also mandate client-side security, especially in e-commerce environments. The most important requirement is the Payment Card Industry Data Security Standard (PCI DSS), which just issued version 4.0.

PCI DSS mandates monitoring and maintaining an inventory of all code on a website’s payment pages, as well as deploying a tamper-detection mechanism that prevents the introduction of credit card-skimming code to payment pages.

Given the dynamic nature of the web and JavaScript, several security aspects must be considered to address client-side vulnerabilities.

1. Real-time monitoring

One of the best ways to ensure full visibility and control on the client side is to implement real-time monitoring.

You need to be able to detect, at any time, if there is any unauthorized script activity on your website.

To minimize the risk and the attack surface, you want to receive alerts when that is happening, as well as, of course, be able to act immediately and block or deactivate any malicious script.

2. Get visibility into third-party scripts

Additionally, it’s also recommended that you are fully aware of all the third-party scripts that are present on your website.

These may come from marketing or analytics tools commonly used on most websites. For this, it’s very helpful to maintain a dynamic inventory of all the scripts present on your website, including first-party and third-party code.

It is also a requirement of version 4.0 of PCI DSS, which requires e-commerce businesses to maintain a full inventory of every script on their payment page.

3. Other client-side attack prevention strategies

There are also other important methods that should be considered:

• First, regularly update and patch all the software and apps associated with your website;
• Beyond that, you should use monitoring and inspection technology that alerts in case of any unauthorized script activity. This should include a detection capability, scanning for anomalies, intrusions, or unknown threats;
• Content Security Policies (CSPs) can help detect and mitigate certain types of attacks. They provide an extra layer of protection but they aren’t enough by themselves: you should also be aware of the shortcomings of CSPs, in that (a) they can be bypassed if they use static whitelists and (b) they lack granularity, relying on a binary “block or allow” approach to third-party access, which fails to address issues such as “allow this unless…”;
• Split front-end applications into smaller components, e.g. public-facing, authenticated, and admin, so as to compartmentalize them and thereby reduce potential blast radiuses;
• Store sensitive website data in a dedicated meta field and keep API keys hidden from public view;
• Use SSL certificates for all websites and keep them up-to-date;
• Exercise extreme caution in the selection and implementation of third and fourth-party scripts (i.e. those that a third-party supplier itself sources from elsewhere);
• Maintain a dynamic inventory of all website scripts, including third-party and first-party;
• Monitor in real-time for any services attempting to access and leak sensitive data on the website;
• Adopt a proactive approach to client-side security, restricting the behaviors of website scripts to prevent them from tampering with forms and/or leaking sensitive data;
• Protect first-party JavaScript from reverse engineering and tampering attempts, both statically and at runtime.

Jscrambler Code Integrity uses obfuscation techniques, code locks, and self-defensive features to protect JavaScript code and block attackers from debugging it.

This is a best practice and an OWASP recommendation for mobile applications, and Jscrambler enables it for JavaScript-based applications, whether running on a mobile device, web browser, or server-side.