Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/6/2020
10:30 AM
Ido Safruti
Ido Safruti
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Client-Side JavaScript Risks & the CCPA

How California's new privacy law increases the liability for securing Web-facing user data, and what enterprises can do to mitigate their risk.

On January 1, 2020, California's new privacy law took effect, which will dramatically increase security risks for any company operating there as well as for third parties that might have access to your data. This is a problem because one of the fastest-growing types of cyberattacks — client-side JavaScript attacks — often targets third-party services. Magecart attacks, for example, frequently focus on compromising plug-ins to major e-commerce platforms such as Magento and Shopify or other popular publishing platforms like WordPress to surreptitiously skim customer data.

The California Consumer Privacy Act (CCPA), which dictates how companies and organizations need to secure the data of users, could drive heavy fines against sites that fail to protect against these attacks. The act can also be a positive force to drive major improvements in your web application security approach.

Why Website Issues Are a CCPA Risk
While the CCPA is the strongest state consumer privacy legislation in the United States, the law also has global reach. A French or a Chinese company that has customers, partners, service providers, or offices in California could be fined if its website is breached and California residents are affected.

However, the exposure is broader than data breaches. CCPA extends liability for compromises of user data to third-party services that web application publishers and operators use. This can include payment processors, chatbot operators, and any other provider of third-party services that integrate with web applications. This could mean large financial exposure if California, which has a track record of aggressive enforcement, pursues fines.

In the European Union, recent interpretations of the 2016 General Data Protection Regulation (GDPR) found that JavaScript attacks by malicious third parties to skim sensitive user data that are not promptly spotted and halted constitute GDPR violations. In these instances, the databases and internal systems were never breached; site code was modified, but not by the site's owner. California adopting this view sets a high bar for website operators.

CCPA also sets up a provision under which people whose data is stolen can sue businesses "as a result of the business's violation of the duty to implement and maintain reasonable security procedures and practices appropriate to the nature of the information." This is a broad mandate to litigation in the event of any type of security incident.

The upshot? CISOs, CMOs, site reliability engineers, and CROs at companies with even small exposure to California should care about liabilities conferred by CCPA on web applications and site code.

CCPA Risks from Third-Party JavaScript Code
Nearly all web applications (including web, mobile web, and hybrid mobile applications) use JavaScript. Increasingly, these applications also use third-party JavaScript libraries and services that are added to their web application. These third-party JavaScript inclusions enhance site functionality in many ways. They also accelerate the speed at which web applications can be constructed, and enable better web application performance by off-loading computationally intensive tasks to third parties.

Unfortunately, it's become hard for companies to keep track of all the third-party JavaScript on their web applications. In a survey of 230 companies averaging 1,000 employees conducted by PerimeterX, 55% of respondents said that more than 50% of their site code is from third parties. Roughly one-fifth said that over 70% of their site code was from third parties, and a surprising 8.3% said they had no idea how much of their site code was third-party code.

Having trouble tracking what third-party services and code companies use complicates auditing for CCPA liabilities. Worse, when third-party libraries and services are hacked or suffer security breaches, the owners of these third-party elements may not notify all website owners that use these libraries and services promptly. The PerimeterX survey found that 42% of respondents have no way to know when and if their site code was changing without their proper authorization.

How to Reduce Risks from Third Parties
Some basic steps can significantly reduce your risk, or, at a minimum, show you performed solid due diligence into the risks third parties confer on your organization (and by extension, on your customers). First, identify all instances of third-party code running on your site. If this code is from third-party open source libraries, then you must treat it as if it's your own code and analyze it for security risks. This includes static code analysis.

For JavaScript from service providers, ask the following questions to gauge their own CCPA risk to you:

  • Do you capture our user data in any way? If yes, please give a detailed explanation how you capture this data.
  • If you capture our data, who has access to that data (additional parties) and how is it secured?
  • How are you checking your code for unauthorized changes? (They should be able to give you a list of steps such as static code analysis and live application scanning.)
  • Do you have full (not partial) SOC 2 or ISO 27001 compliance?

The best offense against CCPA, however, is a good defense. To that end, verify that all your public-facing applications and APIs are properly locked down. All public apps must be guarded by firewalls and other security measures with updated configurations.

To spot any JavaScript attacks early and head off a CCPA risk, deploy a modern artificial intelligence-based anomaly detection platform on real-time data collected in runtime from site visitors, that locates strange code behavior indicating user data is being harvested. [Editor's note: PerimeterX is one of several providers that offer such detection solutions.] These solutions can also give you a real-time updated view of which scripts on your site are actually accessing and collecting personal data, which could provide compliance air cover, as well.

Even if the script is actually a legitimate and uncompromised library or service, compliance rules around data gathering and ability to provide any information on how data is used mandate that site operators must be able to identify every third-party that has access to data, in any way, shape, or form. 

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Disarming Disinformation."

Ido Safruti is a co-founder and CTO at PerimeterX, provider of application security solutions that keep businesses safe in the digital world, detecting risks to web and mobile applications and proactively managing them. Previously, Ido headed a product group in Akamai focused ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 4/7/2020
The Coronavirus & Cybersecurity: 3 Areas of Exploitation
Robert R. Ackerman Jr., Founder & Managing Director, Allegis Capital,  4/7/2020
'Unkillable' Android Malware App Continues to Infect Devices Worldwide
Jai Vijayan, Contributing Writer,  4/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11668
PUBLISHED: 2020-04-09
In the Linux kernel before 5.6.1, drivers/media/usb/gspca/xirlink_cit.c (aka the Xirlink camera USB driver) mishandles invalid descriptors, aka CID-a246b4d54770.
CVE-2020-8961
PUBLISHED: 2020-04-09
An issue was discovered in Avira Free-Antivirus before 15.0.2004.1825. The Self-Protection feature does not prohibit a write operation from an external process. Thus, code injection can be used to turn off this feature. After that, one can construct an event that will modify a file at a specific loc...
CVE-2020-7922
PUBLISHED: 2020-04-09
X.509 certificates generated by the MongoDB Enterprise Kubernetes Operator may allow an attacker with access to the Kubernetes cluster improper access to MongoDB instances. Customers who do not use X.509 authentication, and those who do not use the Operator to generate their X.509 certificates are u...
CVE-2018-21034
PUBLISHED: 2020-04-09
In Argo versions prior to v1.5.0-rc1, it was possible for authenticated Argo users to submit API calls to retrieve secrets and other manifests which were stored within git.
CVE-2020-1895
PUBLISHED: 2020-04-09
A large heap overflow could occur in Instagram for Android when attempting to upload an image with specially crafted dimensions. This affects versions prior to 128.0.0.26.128.