How Third-Party Code Creates Website Risk

TL;DR

Third-party code can expose an otherwise secure website to malware, credential theft, unauthorized data collection, and personal data leakage. Organizations should identify every external vendor, domain, cookie, widget, module, and remote resource operating on their sites, because traditional application security tools become less effective when much of the delivered code is externally controlled.

Transcript

Morning. Um, thank you for coming. Uh, now, before I get started with this, uh, presentation, I'd like to ask you in the audience a couple quick questions, if I may. Um, first off, how many of you in the audience work for a company which either owns or operates a website? Yeah. All right, cool. And how many of you in the audience feel that your web... Read More

Key Insights

• Modern website risk is driven partly by third-party code used for customer identification, fulfillment, streaming, social media, advertising, analytics, hosting, data management, and marketing. These integrations expand functionality but place important portions of the visitor experience outside the website owner's direct control.
• Website content is highly personalized according to user characteristics and devices. The examples show different supplemental content and shipping discounts for different profiles, which means malicious activity or unauthorized collection can also be selectively delivered and remain invisible during ordinary security reviews.
• Data leakage is the unauthorized or prohibited collection of user data by a third party on a website. Cookies and other tracking mechanisms help external collectors follow consumers, creating organizational risk even when no visible malware or obvious website defacement appears.
• Traditional application security tools become less effective as organizations own less of the code delivered through their websites. Scanners may protect internally controlled code well, but outsourced services, cloud components, remote scripts, and dynamically loaded resources create important monitoring gaps.
• A compromised supplier can affect every website that trusts its hosted code. When Gigya's domain was hijacked in November 2015, snippets used by more than 700 publishers called attacker-controlled servers, allowing the Syrian Electronic Army to inject defacement pop-ups.
• Malicious code can be concealed inside apparently legitimate widgets and embedded resources. The compromised BRT Media Flash player loaded an embedded resource containing JavaScript, which contacted a malicious server and created a remote one-by-one pixel used to begin probing visiting systems.
• Ad blockers are not reliable website security controls because rogue advertisements may not yet appear in their filter lists. The presentation also describes PageFair being hacked, causing a paywall intended to counter ad blocking to deliver an N1 Trojan to an unlucky recipient.
• Content management system extensions can obscure rather than directly contain an attack. Third-party PHP modules associated with platforms such as Magento and WordPress may hide malicious logic or contact an external server that later supplies the actual code executed by the website.

Questions & Answers

Q: How does third-party code create website security risks?

Third-party code creates risk because a website may execute scripts, widgets, modules, and remote resources that its owner did not write or fully control. If a supplier, hosted domain, or embedded component is compromised, attackers can use that trusted connection to collect user data, access credentials, deface pages, contact malicious servers, or deliver malware to visitors and employees.

Q: What is website data leakage?

Website data leakage is the unauthorized or prohibited collection of user data by a third party operating on a website. External collectors can use cookies and integrated code to track consumers and gather information. Because collection may vary by profile or device, the activity can occur without appearing consistently to the website owner or its security team.

Q: Why can traditional application security scanning miss third-party threats?

Traditional application security scanning is most effective when an organization owns and can inspect the code it delivers. Modern websites increasingly depend on outsourced services, cloud platforms, hosted scripts, modules, and embedded files. Malicious logic may be obfuscated or fetched later from another server, so scanning the visible or locally controlled code may not reveal the eventual behavior.

Q: What happened when the Gigya domain was hijacked?

In November 2015, Gigya, a customer identification management platform used by more than 700 publishers, had its domain hijacked. Code snippets embedded on publisher websites called servers controlled by the Syrian Electronic Army instead of Gigya's servers. The attackers used that trusted distribution path to inject pop-ups and deface websites, while the same technique could support data collection or malicious attacks.

Q: How can a compromised website widget deliver malware?

A compromised widget can hide malicious logic inside embedded resources rather than displaying it plainly in its primary code. The BRT Media example involved a Flash player that called an embedded resource containing JavaScript. That script contacted a malicious server and created a remote one-by-one pixel, allowing further probing before deciding whether to deliver an attack.

Q: Are ad blockers effective protection against malicious advertising?

Ad blockers are not presented as an effective security solution for malicious advertising. Rogue advertisements may not yet be registered in an ad blocker's filter list, allowing them to appear despite the software. The presentation also shows that anti-ad-blocking services introduce another dependency, illustrated by the compromised PageFair paywall delivering an N1 Trojan to an unlucky recipient.

Q: How do Magento and WordPress extensions conceal malicious code?

Third-party PHP modules used with content management systems such as Magento and WordPress can conceal attacks through obfuscation. The malicious behavior may be hidden within a module or may not arrive until the module contacts an external server. Consequently, inspecting the extension once for plainly visible malicious instructions may not reveal the code eventually introduced into the website.

Q: How should organizations identify website shadow IT risk?

Organizations should examine the full set of external components active on their websites, including vendors, domains, cookies, customer identification platforms, fulfillment tools, streaming services, social widgets, advertising systems, analytics, hosting, marketing platforms, modules, and embedded resources. Visibility must include code loaded remotely and behavior that changes across profiles or devices, because a single inspection may not expose personalized threats.

Summary & Key Takeaways

• Modern websites depend on external services for customer identification, order fulfillment, video streaming, social widgets, advertising, analytics, hosting, and marketing. These integrations create website shadow IT because organizations may neither own nor fully observe the code being delivered to visitors, even when their internally developed application code is secure.

• Compromised suppliers can turn trusted integrations into attack channels. The Gigya domain hijacking redirected embedded snippets from more than 700 publishers toward attacker-controlled servers, while compromised BRT Media and PageFair components demonstrated how widgets, remote resources, and paywalls could conceal malicious JavaScript or deliver malware to website visitors.

• Effective risk management begins with visibility into the complete website supply chain. Organizations need to inventory vendors, domains, cookies, modules, embedded files, and dynamically loaded resources while monitoring their behavior. Code scanning alone cannot reliably detect threats that remain hidden, arrive remotely, or appear only for particular user profiles and devices.