FAQ

3rd party JavaScript refers to scripts, made available from 3rd party vendors, that are embedded into websites to enrich customer experience or enhance analytics. In fact, over 50% of all page requests are 3rdparty calls. These scripts include ads, analytics, widgets, social media extensions and other services intended to make the website more dynamic, interactive, and allow for a personalized user experience.

Google Analytics and Facebook Connect are well known examples of 3rd party JavaScript. Other examples include:

• Chat and sales facilitation tools
• Analytics, heatmaps & metrics
• Social media linkage
• Advertising

Any time 3rd party JavaScript is included on your page, there’s an inherent security risk because these scripts are loaded directly into the browser from remote servers. This integration bypasses entirely the traditional security infrastructure, including firewalls and WAFs, of the website owner. The web experience of end users changes dynamically from user to user making it extremely challenging to monitor each session. The primary concern driving the need for monitoring and control is that the level of access these scripts have to a webpage provides the identical level of control as the website owners own internal script. Every script on the page, no matter its origin, has access and authorship capability allowing content alteration, data exfiltration and traffic redirection to launch other unintended or malicious activity.

Once loaded, these JavaScript components have full access to the web page. They can change the webpage, access all information on it (including forms) and can even record keystrokes and save them. Because 3rd party scripts are hosted on a remote location, site owners are unable to monitor any changes made to them. If and when a third-party vendor is hacked and has its code changed site owners have limited means to dynamically detect this change and no current means to prevent.

Firewall, WAF, secure connection and many other solutions are focused on securing internal servers and the communication between the browser and these internal servers. As defined above, 3rd party scripts are executed on the user’s browser but are called from a remote server. This client-side connection operates completely outside of the security capabilities an organization deploys to secure the server side of the browser session.

Source Defense’s Vice was built to be “transparent” to your third parties, we require no special cooperation or integration to operate seamlessly with them.

Malvertising (a term used to describe “malicious advertising”) is the use of online advertising to spread malware. Malvertising involves injecting malicious or malware-laden advertisements into legitimate online advertising networks and webpages.

Every website today that operates with 3rd party JavaScript is vulnerable to this attack vector. Today, it is difficult to find a website that doesn’t include multiple dozens of 3rd party JavaScript integrations. In fact, over 50% of all page requests are 3rdparty calls. In general, the more 3rd party scripts you use, the higher your risk exposure will be.

When a 3rd party server has been compromised, that infection can spread to anyone interacting with that 3rd Party JavaScript vendor. This means that hacking a popular vendor, can infect thousands of websites with malicious code. A recent attack called Magecart ultimately impacted nearly 800 e-Commerce vendors.

Magecart is a hacking group that has been active for several years, they are most known for one of the biggest credit card theft ever to be discovered affecting at least 800 websites and operating undetected for over 3 years. Security analysts claim that this group strategically targeted 3rd parties to efficiently scale the scope of the attack and impact as many sites as possible.

DAST is Dynamic Application Security Testing, it is usually active on pre-production environments and does not cover live sites. The few who run DAST on a live site will simulate a few user profiles but cannot possibly scale this solution to monitor and detect all web sessions. As third parties change their behavior from user to user, DAST is largely ineffective in detecting attacks on large production networks and completely ineffective at preventing these types of attacks. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.

RASP is Runtime Application Self-Protection, it exists only on the Java virtual machine and .NET Common Language Runtime. Since it will not run on the actual live site, 3rd parties are outside of its detection scope. Again, RASP is not intended as a prevention solution. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.

Monitoring and detection tools will simulate a limited number of user profiles but not all of them. As third parties may change their behavior from user to user, this is not an effective or reliable means to detecting these attacks. Even on occasions where a hack is detected, organizations still need to react to the hack. This requires initiating incident response, removing important tools from your site and replacing them, notifying your users, compliance reporting and damage your brand.

The 3rd party code on your page is only a reference, it will always initiate a call to a 3rd party server. These calls result in additional code downloaded to the browser of each user. Even if you evaluate all the code provided by third party in pre-production deployment, the code might be changed after evaluation. The website owner can be diligent and still be very easily victimized by this universal vulnerability.

In an idle world you could, however, if you wish to stay competitive, you will need 3rd parties integrated on your webpages as they enrich the experience and provide useful analytics and monetization.

The Source Defense solution is architected for deployment and administration simplicity. Although there is a small synchronous component to the solution, that adds approximately 100ms of latency. The solution then operates to isolate introduced 3rd party latency from your content ensuring that the impact of latency from loading multiple 3rd party JavaScript integrations are alleviated. Most deployment recognize a latency and stability improvement when deploying the Source Defense solution.

Browsers loads JS in a synchronous manner, this means that any latency coming from 3rd parties will slow loading of your content. Also, due to the level of access these JavaScript has, it can create components or introduce other malicious or unintended change that will break the structure of your site.

Integration is very simple. It requires the simple copy/paste of two lines of JS to your site’s head section.

Our experts and machine learning can be leveraged to configure the system for you. Should custom configuration be required the administration console provides these tools.

The system is designed to be low touch. The only time you will need to manage it, is when you integrate a new third party to your site.

You will be notified by the administration console of new third-parties identified as being added to your website. Additional alerts are FYI-only and designed to keep the administrator informed of unexpected behaviors. Since the Source Defense solution operates in prevention mode, no action is required from the administrator to address these event notifications. A dashboard can be consulted as needed to keep the administrator informed of how the system is working on your website.

Yes, the system is built for scale, running of a strong CDN with several redundancies.

Any information that exists on your pages is accessible to a hacker via this attack vector. In addition, there are documented cases when the hacker added fields to forms on websites to get additional information from users.

As proven by the Magecart attack that affected over 800 websites for 3 years, this vector is very hard to detect.

Without a real prevention solution, you will need to remove the compromised third party to stop an attack. This then incurs operational costs which includes identifying an alternative solution. Unfortunately, removing a compromised 3rd party JavaScript vendor does not reduce your risk exposure as the alternative vendor introduces the same level of risk to your website.

You will need to trigger your incident response teams, engage in cyber analysis to understand the scope of the breach. Then contact your users and start dealing with the aftermath. If you are obligated to GDPR or PCI compliance, you should follow these protocols.

Any regulation that defines customer data privacy and ensure control of customer data is vulnerable. This means that websites operating today cannot ensure compliant operation since they cannot ensure the privacy of connections since unlimited access privileges and visibility to all transacted data is accessible to these 3rd party JavaScript vendors. In fact, the GDPR goes as far as specifying liability to the website over 3rd party behavior specifically. As long as you have 3rd party JavaScript vendors integrated on your website you are essentially non-compliant with customer data privacy.