How Third-Party services often clash with website security mechanisms

Advertising has been ever-present on the Internet for years. For site operators, it is often the best way to earn money from their web content. However, advertisements and other third-party services often clash with security mechanisms of websites. Operators have to choose between useful features and IT security. This is what CISPA-PHD student Marius Steffens has discovered together with Marius Musch and Martin Johns from TU Braunschweig under the direction of Faculty Ben Stock. The results of their study, "Who's Hosting the Block Party? Studying Third-Party Blockage of CSP and SRI," were recently presented by the researchers at the Network and Distributed System Security (NDSS) conference, one of the most important cybersecurity conferences in the world.

An advertising banner at the top, a live chat form in the right corner and a Google map at the bottom: According to Marius Steffens, almost every page on the web contains code that does not originate from the page operators or developers themselves, but from third parties. The integration of third-party services is often essential for site operators because they earn a large part of their money from advertising. On the other hand, they can offer their visitors additional functions. The fact that many things are interconnected on the web is very convenient for end users, explains Steffens. For site operators, however, the integration of third-party services often poses a security risk, says the 24-year-old, who has been researching at CISPA in Faculty Ben Stock's team since 2018. 

He and the research team examined more than 8,000 popular sites in a longitudinal study conducted over a 12-week period. They found that more than 70 percent of the examined pages contained third-party code that would limit the functionality of a so-called content security policy (CSP), even if the page owners themselves specially adapted their code to it. The CSP security concept is intended to prevent attacks such as cross-site scripting (XSS). In XSS, attackers try to inject malicious code into the code of supposedly trustworthy websites, such as a bank website, and use it to steal confidential information such as users' passwords. "Such attacks can have devastating effects," Steffens says. One of the best-known cases is that of the so-called MySpace worm Samy in 2005, which a young hacker used to gain a million friends on the social media platform and contaminate just as many accounts with a comparatively harmless virus. MySpace had to temporarily shut down operations completely to clean up the profiles. A CSP, he said, can prevent such attacks by determining which source code is allowed to be executed and which is not. "If the CSP is configured correctly, the browser prevents the attack," Steffens explains. At least in theory.

 Since its introduction, the CSP security concept has undergone constant development and more features have been added. Nevertheless, Steffens says, in practice, it doesn't work for website operators the way they require it to. By default, for example, the mechanism blocks inline scripts, i.e. those that are located directly in the code. However, the fact that developers often want to use these scripts means that they restrict the functions of their CSP for this purpose, which means that attacks can no longer be prevented, says Steffens.

There are also security problems with the second mechanism examined in the NDSS paper, Subresource Integrity (SRI), which is intended to protect the initial provider and its site from unwanted changes to the imported scripts if, for example, one of the third-party providers has been attacked. According to the researchers, this is at least limited to more than half of all the sites examined. With SRI, it is determined that the code integrated by third-party providers is only executed if it exists unchanged in a certain form. In practice, however, the scripts are constantly changing, says Steffens. They are continuously updated, but even the smallest changes to the scripts cause SRI to prevent their execution. In addition, the scripts themselves could in turn contain and run other scripts that have not been checked by SRI, thus overriding their functionality. So once again, theory and practice collide, often forcing website owners to abandon IT security in favor of desired features.

"Third-party vendors need to be clear about the impact they have on web security," Steffens says. The researcher concludes that the security community also needs to think about how the mechanisms can be adapted so that they can be reasonably used by developers in practice.

The text was translated by: Tobias Ebelshäuser