Send email Copy Email Address
2021-11-23
Annabelle Theobald

Too complex, too time-consuming, too expensive

Installing a content security policy (CSP) on websites could be a real game-changer in terms of web security. It could - because there are still too many problems with it. Often, sensible and effective use of the security mechanism already fails because website developers make mistakes when configuring it. In a qualitative study, CISPA researchers Sebastian Roth and Lea Gröber have for the first time shed light on exactly where the pitfalls for developers lie. They presented their paper "12 Angry Developers - A Qualitative Study on Developers' Struggles with CSP" at the renowned security conference CCS.

The security mechanism CSP, which was developed in 2012 and is primarily intended to reduce the risks of so-called cross-site scripting attacks, is proving to be a blunt sword in the fight against the attacks, even after many years and several revisions. "At the same time, CSP can work - and then the mechanism is awesome," explains Sebastian Roth. Why there are more problems than benefits up to now has been researched for many years. "So far, however, no one has asked the developers where the problems actually lie for them when rolling out a CSP," says Roth, who conducts research in the research group of CISPA faculty Dr. Ben Stock. Together with Lea Gröber from the Usable Security group of CISPA Faculty Dr. Katharina Krombholz, Roth has made up for this and uncovered some practical problems in a study with twelve developers.

But first, the purpose and function of the security mechanism: One of the most common types of attack on the Web, and thus a major security risk for users, is cross-site scripting (XSS), in which attackers inject malicious code into websites. If they succeed, they can gain access to sensitive user data such as passwords or credit card numbers.

A gateway for attacks is created by the fact that many website operators integrate services - such as advertising, maps, or payment services - and thus foreign code on their pages. This code must be repeatedly reloaded by the web browser in order to keep it up to date, explains Roth. "However, many sites have vulnerabilities in their code or that of third-party vendors that make the browser think code to be reloaded comes from a legitimate source, when in fact it's malicious code." With a CSP, developers can prevent this and specify exactly which source code can and cannot be loaded from.

"In fact, all developers need to do is create a list of allowed sources." This sounds simple, but in practice, it is not, as Roth and Gröber's study shows. Simply compiling the various sources from which code is to be loaded is often more complicated than expected at companies, because different teams of developers are responsible for the design and content of the pages, and a smooth process can only be guaranteed if all the important information comes together in one place. In addition, third-party developers often include code from other websites, which must also be included in the list to ensure that everything works. According to Roth, it is often not very clear which of these are involved.

"Different web browsers also support the security mechanism differently. Our study showed how problematic this can be for developers." For example, it affects how errors are reported to developers and how useful the provided information is. In addition, in some browsers, extensions - which enable additional functionality - produce error messages that are a huge time commitment for developers to follow up on. "This quickly makes rolling out CSP a financial issue for companies as well."

Many developers are also unaware of what functions the CSP provides and what exactly it protects against. "If developers have the wrong idea of where and how the CSP works, they make mistakes." Roth says there is a lack of tenable sources that provide appropriately prepared information. "Some kind of FAQ would help," Roth says. Info from poor sources has so far repeatedly misled developers their work.

Another major, but already known, problem is that the smooth functioning of the CSP often requires developers to rewrite program code - not only on their own side but also on the side of third-party providers. "But they often have no interest at all in investing time and effort here," says Roth. "Unfortunately, the mentality of many companies is often that: Security is a welcome addition, but not something you have to have." Finding a solution to this is one of the biggest challenges, Roth says.

He is convinced that CSP can mean a big step toward more web security in the future. "So far, though, there are unfortunately still too many construction sites." The World Wide Web Consortium, a body that standardizes new techniques on the World Wide Web and makes a recommendation for CSP, recently invited Roth and Gröber to give a talk, where the young researchers presented these and other results of their study. "Fixing all the technical problems will probably take time, but you can work on communication right now and take an important step toward more Web security."

translated by Oliver Schedler