Third-party scripts are scripts that are developed externally and added to an organization’s website for various purposes. These scripts can have great benefits, but they can also introduce security risks for businesses.
Third-party scripts are added to an organization’s website by different teams for different purposes. Common categories of third-party scripts include:
Related Category: Application Security
Type of Content: Articles
All of these are worthy goals, and it makes sense that a company would use code developed by an organization that specialize in these areas to achieve them more efficiently. However, this means that a company’s website can end up containing a great deal of executable code that was developed by an outside party.
Using third-party scripts means you trust that the script’s developer hasn’t inserted malicious functionality into the code and has secured it against attackers trying to do the same. Unfortunately, this isn’t always the case so third-party scripts can pose significant security risks.
Most development teams have strict rules on adding code to their codebase and managing potential errors. The trend toward DevOps and DevSecOps means that no code is added to the official codebase until it has been fully tested and proven to pass all functionality and security tests.
The use of third-party scripts undermines this process. Many third-party scripts are added by the marketing team using tag managers after code has exited the development pipeline. These tag managers pull code from a variety of different external locations and run it within the corporate website.
As a result, an organization’s website includes a massive amount of code that has not undergone testing and was likely added by employees with limited development and security knowledge. This creates a scenario where third-party add-ons can threaten the usability and security of the corporate website.
Unpatched vulnerabilities are one of the greatest threats to web security. The massive number of third-party libraries used in production code means that a developer only has visibility into a small fraction of the code used to implement their application. As a result, it’s difficult to ensure that external code does not contain unpatched and exploitable vulnerabilities.
The introduction of third-party scripts only expands this potential attack surface. With even more external code, which developers have no visibility into, the probability of an error sneaking in is even greater.
The fast-moving nature of marketing only makes this problem worse. The marketing team is unlikely to perform any testing before trying out a new script, and existing scripts may be left in place indefinitely and forgotten as long as they don’t break anything. As a result, the potential attack surface of an application continues to grow.
WordPress plugins are a great example of third-party scripts that commonly introduce vulnerabilities into a website. WordPress users include plugins in their pages to implement ecommerce functionality, perform analytics and similar actions. However, even the most popular WordPress plugins commonly contain vulnerabilities.
For example, in March 2021, two vulnerabilities were patched in the Facebook for WordPress plugin that enabled an attacker to run malicious code on a vulnerable WordPress page. These vulnerabilities affected over 500,000 WordPress pages and could lead to a major data breach or other security incident if exploited.
While vulnerabilities can unintentionally creep into third-party code, cyber threat actors commonly take advantage of third-party scripts in their attacks. Injecting datastealing code or other malicious functionality into a single third-party script could enable an attacker to target many different websites with a single campaign.
The practice of injecting malicious functionality into websites and third-party scripts is such an effective attack vector that it became a signature of Magecart, a hacking group behind a series of cyberattack campaigns designed to inject web skimmers into ecommerce sites.
A web skimmer or digital skimmer is a malicious script that takes advantage of the rules regarding how data is shared between the various scripts running within a website. When credit or debit card information is entered into a site, a web skimmer will copy that data and send it to the attacker for use in fraudulent transactions.
The Magecart group used a variety of different techniques to inject web skimmers into ecommerce pages, including exploiting vulnerabilities and injecting malicious content into third-party scripts. One of their attacks, which targeted British Airways, led to the UK’s Information Commissioner’s Office assigning the largest GDPR penalty to date.
>> Download Article to continue reading.
FortiOS, the Fortinet network operating system, is the heart of the Fortinet Security Fabric. This operating system, or software, is at the core of the Security Fabric and ties all components together to ensure a tight integration across an organization’s entire Fabric deployment.
Ask a group of security analysts about the challenges of working in cybersecurity, and you’ll likely hear some common themes....
In order to stay competitive and reduce costs, smart enterprises are constantly on the hunt for disruptive ways to leverage technology. They’re moving towards hybrid IT environments because they recognize the benefits of faster implementations and high cost savings that come with moving from on-premises to cloud-based applications and infrastructure.
In the decades since “cloud computing” first achieved buzzword status, its benefits have been widely proven. And now that the shift to both dynamic work environments and digitized customer experiences has rapidly accelerated, migrating these applications to the cloud is more important than ever.
Organizations are rapidly adopting digital innovation (DI) initiatives to accelerate their businesses, reduce costs, improve efficiency, and provide better customer experiences. Common initiatives involve moving applications and workflows to the cloud, deploying Internet-of-Things (IoT) devices on the corporate network, and expanding the organization’s footprint to new branch locations.
There’s a lot of truth to the statement that all companies are technology companies. After all, the core focus of a technology company is to deliver software, whether internally to empower the workforce or externally to serve customers. Technology companies also maintain servers to create, collect, store, and access data—which is now the norm for organizations worldwide, whether public or private, commercial or enterprise.
The drawbacks of passwords are well known – simply put, they can be hard to remember, easy to hack and a general nuisance for both end users and security personnel. However, passwords remain a staple of many organizations’ security frameworks, despite the fact that the cybersecurity industry has been calling for the death of passwords for nearly 20 years now.
Retail banking includes traditional players such as brick-and-mortar banks that operate at community, national, or even international levels. It also includes many new players, such as challenger banks that only operate online, financial technology companies (FinTechs), and nonfinancial companies seeking to disrupt the status quo and compete for market share, such as Amazon, Apple, and Facebook. Unlike traditional banks, these new players are often digital natives that bring some strategic “big-tech” advantages to serving customers in an increasingly online world.
Device trust is the process of analyzing whether a device should be trusted and therefore is authorized to do something. It’s critical that the devices accessing company data are trustworthy. Determining which devices should be trusted is a unique decision made by each organization depending on their risk tolerance and compliance requirements.
The world of Identity and Access Management (IAM) is rarely controversial. But today, there is a battle brewing in how we-as an industry-talk about customer-facing use cases for IAM. The world of Identity and Access Management (IAM) is rarely controversial. But today, there is a battle brewing in how we-as an industry-talk about customer-facing use cases for IAM. Many are starting to refer to this as Customer IAM or Consumer IAM, both abbreviated as CIAM. CIAM does have some unique requirements. But that does not mean that you must use a product that only focuses on CIAM. Okta’s approach is to offer a broad IAM cloud service with a strong foundational platform and functionality that enables CIAM use cases—we believe ultimately a better long-term choice.