<a href="https://www.livechat.com/chat-with/14893845/" rel="nofollow">Chat with us</a>, powered by<!-- --> <a href="https://www.livechat.com/?welcome" rel="noopener nofollow" target="_blank">LiveChat</a>
Multilogin | Content Security Policy: Say 'Goodbye' To Your Privacy

Content security policy: say 'goodbye' to your privacy extensions

AUGUST 23, 2019 | FINGERPRINTS

There are certain technologies that are being adopted as a standard because they enhance safety levels for both websites and the users who visit them. Content security policy is an added layer of security that helps browser prevent specific cyber-attacks from happening, and it’s being widely adopted as a basic safety measure across all sites and browsers.

The reason behind its popularity is that it helps prevent certain types of attacks, namely cross-site scripting and other data injections threats.

You may then find yourself wondering: What does content security do in the first place? How does a security measure like CSP put online privacy at risk? And, what is the best way to avoid this risk?

Before diving fully into each one of these questions, you need to understand why content security policy is important. You also need to identify the threats involved for users who decide to ignore CSP altogether. In addition to this, we will go over the best option to safe-keep your identity and prevent cyber-attacks at the same time.

Same origin policy

There are a few terms you need to get familiarized with before understanding CSP. The first and most important is the same-origin policy, also known as SOP. The same-origin policy was created to prevent unauthorized sites from gaining access to certain pieces of sensitive information that are stored on a website.

SOP separates many elements into isolated environments, including cookies and Javascript scripts. For example, if the site www.firstsite.org contains an HTML element that loads a second page such as www.secondsite.org, the first site will not be able to access the second site’s cookies or inject it with Javascript scripts, and vice versa.

Even if both of them are running in the same browser window and show the same URL, thanks to the single-origin policy, neither will be able to extract information or run Javascript scripts on the other site’s origin.

This mechanism forbids access to cross-origin content, and it is what prevents random websites from reading or changing data on your Twitter or Paypal accounts while you are logged into them.

As you may have guessed, SOP has become one of the most important security principles found in all browsers today. It basically set the premise for other security standards that revolve around allowing access only to authorized sources.

In theory, the Same Origin Policy is a perfect solution. However, attackers quickly devised ways to bypass it and these have resulted in major security threats for websites and users alike.

What are cross-site scripting (XSS) attacks?

Cross-site scripting, also known as XSS, is a method that can help bypass the Same Origin Policy. XSS attacks are a major problem because attackers inject malicious scripts into trusted websites without being detected. Without knowing this, users may be enticed to clicking on a link or executing a script that is not safe.

There are many flaws that allow cross-site scripting attacks, and they can be exploited in a variety of ways. Whenever websites use dynamic HTML that does not sanitize user input, attackers are able to introduce their own malicious code.

When malicious code is introduced through these channels, web browsers will see the code as being from the website it’s being executed in, so it will gladly carry out the task without hesitating or identifying any threats.

XSS attacks can target unwary users and send pieces of malicious scripts that carry out a number of tasks. Users are not aware they received any script at all, and their browsers happily execute them because they appear to be coming from a trusted source.

Cross-site scripting attacks can inject a malicious script that may gain access to cookie files, other website data from web page context, and various sensitive pieces of information. Severe attacks can even rewrite the contents of the HTML page, which can lead to extended security problems in the long run. Gaining access to this information would enable attackers to view sensitive information and make requests on users’ behalf.

There have been many notable XSS attacks recorded, some of which have involved intelligence agencies, social media networks, and even major email platforms. For instance, in the mid-2000s, an XSS worm known as Samy became one of the fastest-spreading viruses after propagating to more than 1 million Myspace users just hours after it was launched.

Cross-site scripting has become a major problem which has led to the development of CSP, in order to set higher security standards. The biggest issue with modern browsers, and what makes them vulnerable to XSS attacks, is that they can’t tell trustworthy and suspicious domains apart. When you make a request through a browser, it happily carries out all received scripts because it’s unable to tell which ones can or can’t be trusted.

Content security policy

Now that we went over SOP and XSS attacks, we can start covering content security policy. As mentioned before, CSP is an additional layer of security that enables websites to create a whitelist of resources that can be trusted within the context of that site. When implementing CSP, browsers will ignore all requests made to sources that don’t appear on the white list.

Without CSP, browsers are vulnerable to various forms of XSS attacks because they can’t distinguish between scripts that are part of a site and ones that have been injected by a third party.

When you access a website that uses CSP, the site sends a list of sources to your browser. Then your browser happily complies and carries out any request that is made to the sources that appear on the whitelist.

With websites that implement CSP, your browser will make sure the source code of the script is on the whitelist before complying. If the origin is not listed as safe, your browser will ignore the request completely. That way, even if there are malicious scripts injected into a site you visit, CSP enables your browser to identify these malicious scripts and ignore them completely.

As you can tell by all this information, CSP is actually a great security tool. So, how can it affect online privacy negatively?

The privacy implications of using CSP

Content security policy is a great security measure because it helps prevent cyber-attacks. Unfortunately, there are also privacy implications that come as a direct result of using CSP. Before covering these ramifications, we must review the basics of CSP, learn a little more about the first version, and understand how modern CSP operates.

A version known as CSP 1.1 is widely used and accepted as a standard, however, it was based on the first policy that was created as a predecessor. The first versions, known as CSP 1.0, was developed to fend off and protect against XSS attacks. CSP 1.0 also stated that a website should not interfere with the operations of any browser extension that is installed by the user.

However, this model became obsolete after the release of CSP 1.1, which is slowly being adopted by all major web platforms. CSP 1.1, sometimes referred to as strict CSP, can interfere with extensions and stop them from injecting script into websites. This means that popular privacy extensions, such as User Agent Switcher and Random Agent Spoofer, will not work on websites that have a strict policy.

This creates a huge issue for users who want to maintain high levels of privacy and evade intrusive web tracking. Because extensions can’t change the state of a browser, they depend on injecting Javascript into the website in order to change the parameters and prevent browser fingerprinting. Pretty clever, isn’t it?

But, websites that use CSP 1.1 can impede extensions from rewriting the content of a page, including Javascript scripts. Because privacy extensions work injecting Javascript in the page code, they just cease working altogether.

If a site uses browser fingerprinting mechanisms that can be combated by privacy extensions, the site is likely to implement CSP 1.1, so they can impede these extensions from working. In other words, they would be able to track and fingerprint users successfully.

It’s worth mentioning that certain configurations of CSP 1.1 allow extensions to inject scripts into websites and rewrite page content, but this option is not usually preferred by any site. They have an incentive to using CSP configurations which disable extensions that prevent browser fingerprinting. By doing this, websites can increase security levels and identify their visitors efficiently at the same time.

At this point, popular platforms such as Facebook, Twitter, and Github use CSP configurations that allow extensions to inject script into a site. But, CSP 1.1 is spreading like wildfire, and because websites have an extra incentive to disable extensions, most major websites are starting to make the switch.

For instance, PayPal has already switched over to a configuration of CSP 1.1 that does not allow third-party script injection, so no privacy extensions can be used on their site anymore.

How to find out if a website utilizes CSP

If you are wondering if any of the websites you visit on a regular basis use CSP, you can follow the instructions below to verify if CSP is active on that website.

How to check if a website uses CSP:

  • Open a website in any Chromium-based browser, e.g. Chrome

  • Right-click anywhere on the website and choose “Inspect”

  • Go to the “Network” tab

  • Now click F5 to refresh the page

  • During the page loading, all requests should appear in the Inspector

  • Click on the very first line in the list of requests (list of requests is under the “Header” tab)

  • If you see “content-security-policy” in the “Response Headers” section, then CSP is on

CSP and browser fingerprinting

Implementing CSP can help prevent data injection attacks, but they also pose a big problem when it comes to online privacy and browser fingerprinting. Privacy extensions that previously allowed users to surf the web without compromising their identity are likely to experience issues thanks to CSP 1.1.

This doesn’t mean that online privacy is doomed, but it should be more of a warning that privacy extensions will soon become a thing of the past. Privacy extensions such as User Agent Switcher and Random Agent Spoofer depend on injecting script into a website in order to effectively manipulate fingerprinting parameters.

Without online privacy extensions, you are more susceptible to browser fingerprinting and the negative consequences that come with it. As we mentioned before, this characteristic is encouraging websites to use a version of CSP 1.1 that is not extension-friendly, rather than a configuration that allows extensions to run without any disruptions.

Preventing XSS attacks and browser fingerprinting

CSP has become a crucial component of all major browsers, and the technology itself has a number of benefits. Although there are some online privacy implications, these can be mitigated by using the right methods.

Keep in mind that turning off CSP will not only put your device at risk of a cyber-attack, but it will also create an additional fingerprint. Most browsers actively allow CSP, so turning it off would put you in a very small group of users who disabled this security feature on their browsers, making you more identifiable.

Multilogin still provides a viable alternative to combating browser fingerprinting. Moreover, users often ask us how Multilogin reacts when facing a website that uses CSP 1.1, but this depends heavily on the type of browser you are using.

If you use Multilogin in combination with Chromium, Firefox or any other “regular” browser, they would ignore CSP completely by default. However, this is not ideal because it makes your browser vulnerable to XSS attacks. Remember that CSP 1.1 can turn off all privacy extensions and reveal a user’s browser fingerprint, but when you use Multilogin, you prioritize online privacy over XSS attacks. When Multilogin is used with regular browsers, CSP is automatically switched off in order to keep the real fingerprint from being revealed.

The best solution that helps maintain high levels of online privacy and prevent XSS attacks may be to use a fingerprint management method that does not depend on injecting Javascript into websites.

Stealthfox is a Firefox-based web browser that can help you maintain high levels of online privacy when visiting sites that use CSP 1.1. Because it’s already bundled with Multilogin, Stealthfox allows you to efficiently combat browser fingerprinting while still being protected from XSS attacks.

Instead of managing the parameters during the loading of the pages with Javascript as do most extensions, Stealthfox configures the browser’s parameters when it is launched. This means you can use a CSP-compliant browser that will safeguard you against XSS attacks while keeping your real information hidden.

In conclusion

Content security policy offers a good safety net that helps protect against data injection attacks. That being said, CSP 1.1 policies also provide a huge loophole that can render privacy extensions completely useless.

The truth is that CSP is far from perfect, but it will soon become a key component of all internet platforms, regardless of size. Moreover, a big portion of the most popular websites is leaning towards CSP 1.1 because it can disable privacy extensions and allow for effective fingerprinting. Privacy extensions may still work on popular websites now, but they are in danger of becoming obsolete thanks to the widespread of CSP 1.1.

The best way to prevent XSS attacks while still maintaining high levels of privacy is to use a browser that has fingerprint management capabilities.

Stealthfox can configure the parameters used to identify your fingerprint as soon as the browser is launched. This will help you maintain high levels of privacy while CSP keeps you safe from data injection threats.