cPanel Forums

Page Shield can now watch for malicious outbound coections made by third-party JavaScript code

Many websites use third party JavaScript libraries to cut development time by using pre-built features. Common examples include checkout services, analytics tools, or live chat integrations. Any one of these JavaScript libraries may be sending site visitors’ data to unknown locations.

If you manage a website, and you have ever wondered where end user data might be going and who has access to it, starting today, you can find out using Page Shield’s Coection Monitor.

Page Shield is our client side security solution that aims to detect malicious behavior and compromises that affect the browser environment directly, such as those that exploit vulnerabilities in third party JavaScript libraries.

Coection Monitor, available from today, is the latest addition to Page Shield and allows you to see outbound coections being made by your users’ browsers initiated by third party JavaScript added to your site. You can then review this information to ensure only appropriate third parties are receiving sensitive data.

Customers on our business and enterprise plans receive visibility in outbound coections provided by Coection Monitor. If you are using our Page Shield enterprise add-on, you also get notifications whenever a coection is found to be potentially malicious.

Covering more attack surface with Coection Monitor

Coection Monitor expands the net of opportunities to catch malicious behavior that might be happening in your users’ browsers by complementing the visibility provided by Script Monitor, the core feature of Page Shield before today.

While Script Monitor is focusing on analyzing JavaScript code to find malicious signals, Coection Monitor is looking at where data is sent to. The two features work perfectly together.

Very frequently, in fact, client side compromises within the context of web applications result in data exfiltration. The most well known example of this is Magecart-style attacks where a malicious actor would attempt to exfiltrate credit card data directly from the application’s check out flow (normally on e-commerce sites) without changing the application behavior.

These attacks are often hard to detect as they exploit JavaScript outside your direct control, for example an embedded widget, and operate without any noticeable effect on the user experience.

Complementing Content Security Policies

Page Shield uses Content Security Policies (CSPs) to receive data from the browser, but complements them by focusing on the core problem: detecting malicious behavior, something that CSPs don’t do out of the box.

Content Security Policies are widely adopted and allow you, as a website administrator, to tell browsers what the browser is allowed to load and from where. This is useful in principle, but in practice CSPs are hard to maintain for large applications, and often end up being very broad making them ineffective. More importantly, CSPs provide no built-in mechanism to detect malicious behavior. This is where Page Shield helps.

Before today, with Script Monitor, Page Shield would detect malicious behavior by focusing on JavaScript files only, by ruing, among other things, our classifier on JavaScript code. Starting today, with Coection Monitor, we also perform threat intelligence feed lookups against coection URL endpoints allowing us to quickly spot potentially suspicious data leaks.

Coection Monitor: under the hood

Coection Monitor uses the coect-src directive from Content Security Policies (CSPs) to receive information about outbound coections from browsers.

This information is then stored for easy access and enhanced with additional insights including coection status, coection page source, domain information, and if you have access to our enterprise add-on, threat feed intelligence.

To use Coection Monitor you need to proxy your application via Cloudflare. When turned on, it will, on a sampled percentage of HTML page loads only, insert the following HTTP response header that implements the Content Security Policy used to receive data:

content-security-policy-report-only: script-src 'none'; coect-src 'none'; report-uri <HOSTNAME>/cdn-cgi/script_monitor/report?<QUERY_STRING>

This HTTP response header asks the browser to send information regarding scripts (script-src) and coections (coect-src) to the given endpoint. By default, the endpoint hostname is csp-reporting.cloudflare.com, but you can change it to be the same hostname of your website if you are on our enterprise add-on.

Using the above CSP, browsers will report any coections initiated by:

• <a> ping,
• fetch(),
• XMLHttpRequest,
• WebSocket,
• EventSource, and
• Navigator.sendBeacon()
  

An example coection report is shown below:

"csp-report": {
    "document-uri": "https://cloudflare.com/",
    "referrer": "",
    "violated-directive": "coect-src",
    "effective-directive": "coect-src",
    "original-policy": "",
    "disposition": "report",
    "blocked-uri": "wss://example.com/",
    "line-number": 5,
    "column-number": 16,
    "source-file": "",
    "status-code": 200,
    "script-sample": ""
}

Using reports like the one above, we can then create an inventory of outbound coection URLs alongside which pages they were initiated by. This data is then made available via the dashboard enhanced with:

• Coection status: Active if the coection has been seen recently
• Timestamps: First seen and last seen
• Metadata: WHOIS information, SSL certificate information, if any, domain registration information
• Malicious signals: Threat feed domain and URL lookups*

^* URL feed lookups are only available if the full coection path is being stored.

A note on privacy

At Cloudflare, we want to ensure both direct customer and end customer privacy. For this reason, Coection Monitor by default will only store and collect the scheme and host portion of the coection URL, so for example, if the endpoint the browser is sending data to is:

https://coection.example.com/session/abc

Coection Monitor will only store https://coection.example.com and drop the path /session/abc. This ensures that we are minimizing the risk of storing session IDs, or other sensitive data that may be found in full URLs.

Not storing the path, does mean that in some specific circumstances, we are not able to do full URL feed lookups from our threat intelligence. For this reason, if you know you are not inserting sensitive data in coection paths, you can easily turn on path storage from the dashboard. Domain lookups will continue to work as expected. Support for also storing the query string will be added in the future.

Going further

Script Monitor and Coection Monitor are only two of many directives provided by CSP that we plan to support in Page Shield. Going further, there are a number of additional features we are already working on, including the ability to suggest and implement both positive and negative policies directly from the dashboard.

We are excited to see Coection Monitor providing additional visibility in application behavior and look forward to the next evolutions.