DBS App Security Workshop

Page Shield

Use Case

Acme Corp faces challenges in securing their web applications from client-side attacks and they are concerned attackers will target vulnerabilities in their web application's scripts to manipulate user data, compromise security, or execute malicious actions.

To achieve PCI DSS compliance, Acme Corp uses traditional solutions like content security policies (CSPs) to manage third-party scripts on their web application. However, security teams have reported that CSPs are a challenge for them to manage because:

  1. Complex Maintenance: Acme Corp struggles to maintain CSPs due to the continuous addition and removal of third-party scripts by developers, making it difficult to accurately understand and manage the full extent of required scripts.
  2. Difficulty in Setting Restrictions: The level of restriction on CSPs is challenging to configure, as some scripts reference other scripts. Blocking these referenced scripts risks breaking the page functionality, while allowing all references compromises security, hindering their PCI DSS compliance efforts.
  3. Limited Security Verification: CSPs offer a simplistic allowlist approach, lacking the capability to verify if scripts are referencing malicious domains or have been compromised to execute malicious behavior, leaving Acme Corp vulnerable to sophisticated attacks.

To address these pressing concerns, Acme Corp has turned to Cloudflare Page Shield to:

  • Implement CSP to monitor and catalog scripts and connections on your website
  • Access dashboards for oversight of script and connection activities
  • Automatically detect and classify malicious script activities

Lab environment

This lab is a bit special. That's because when we spun up your lab, we preconfigured couple things for you. Let's now go through what exactly we did.

We preconfigured a web page for you that lives on the *cfdemolab.xyz/contact/received endpoint. On this page, we have many third-party scripts running and we have been sending traffic to the endpoint so that the Page Shield can sample the responses and present the active connections and scripts.

Ok, with that out of the way, let's get to the labs!

Tasks

1.Review Active Connections and Scripts

Let's start by looking at what the Page Shield learnt about the traffic coming to the web application we preconfigured. Navigate to Security ‣ Page Shield.

In the first tab titled Monitors, you will find a list of connections and monitors that Page Shield has seen on your page for more than 3 times in the last 7 days.

Monitors help to provide greater visibility into active scripts and connections on Acme Corp's domain. With this visibility, we can now review the full list and investigate unexpected or malicious scripts and connections.

The dashboard view here shows only Active scripts (which have more than 3 reports in the last 7 days). To view all scripts, you can select View all scripts.

This presents all scripts discovered with the status, last seen timing and hostname and URL the script was discovered on.

To enforce Content Security Policies (CSP) from Cloudflare Page Shield, Acme Corp will need to gather the full list of active scripts and share it with the developers to validate which scripts are required for application function. You can do this selecting Print Report. This will generate a report on all active scripts which can be shared with the developers.

2.Review Malicious Resources

While waiting for the developers to get back on the list, Acme Corp also needs to investigate malicious resources. Let's go back to Monitors to take a look at the malicious detections.

Page Shield implements different mechanisms to check if a resource is malicious. These mechanisms are:

  • Malicious URL checks: Whether the connection’s target URL is known to be malicious according to threat intelligence feeds.
  • Malicious domain checks: Whether the connection’s target domain is known to be malicious according to threat intelligence feeds.
  • Malicious script detection: Whether Cloudflare’s internal systems consider the script malicious or not, and what is the score of the current script version (1-99).

All scripts and connections considered malicious will appear at the top of the list in the Monitors dashboard, regardless of their status. Let's take a look at a few examples.

Click into Details to understand the malicious detection. Let's first take a look at the malicious detection for https://cryptomining.testcategory.com/1.js

Under the script details, you will see the following fields:

  • Malicious Code: Cloudflare’s internal systems have not flagged the script to be exhibiting malicious behavior.
  • Malicious URL: The script has not been flagged by threat intelligence feeds based on the URL.
  • Malicious domain: This shows that the connection’s target domain is known to be malicious according to threat intelligence feeds.
  • Malicious category: The threat intelligence feeds have flagged the domain as one associated to cryptomining.

What you can see is that Acme Corp's page is running third-party scripts from an external domain which has been flagged for being associated to cryptomining. This needs to be highlighted to the Security team and validate the use of this script with developers.

Next, let's check out another malicious script detection for https://www.americantourister.co.kr/on/demandware.static/Sites-AmericanTouristerKR-Site/-/ko_KR/v1665602114344/js/kakaoStoreLocator.js

Under the script details, you will see the following fields:

  • Malicious Code: Cloudflare’s internal systems consider the script malicious and have assigned it a score of 1 for exfiltration.
  • Malicious URL: The script has not been flagged by threat intelligence feeds based on the URL.
  • Malicious domain: The script has not been flagged by threat intelligence feeds based on the domain.
  • Malicious category: As the threat intelligence feeds have not flagged the domain or URL as malicious, there is also no Malicious category shown.

Here you can see even if the domain itself may not be malicious, the scripts running on Acme Corp's site may still be compromised and Acme Corp would not normally have visibility over this as they do not manage the security of the third-party script. However, with the help of Page Shield, you can now flag this out for the Security team's visibility.

3.Enforcing a positive security model

After some validation from the developers, you now have your list of scripts that are required for proper application function. It is now time to enforce a positive security model with policies.

The list of resources that should be allowed are:

  • Scripts:
    • Allowed scripts
      • *.cfdemolab.xyz
      • *.useinsider.com 
    • Directive Value: 'self' - Refers to the origin from which the protected document is being served
  • Connections: connect-src
    • Allowed Connections
      • *.hookb.in
    • Directive Value: 'self' - Refers to the origin from which the protected document is being served

Now that we have our list, we can navigate back to the dashboard to Page Shield ‣ Policies.

Select Create Policy to define allowed scripts.

As an independent exercise without further guidance from us, set up the policy to cover your web application https://*.cfdemoloab.xyz/contact/received.

Hint: This uses the same Cloudflare Ruleset Engine as the Cloudflare WAF.

When you're done, scroll below set the directtives to be allowed.

First, select the script directive

Page Shield will display script directive suggestions based on the script detections on your page. Simply select the scripts that have been provided from the developers.

Next, set the eval function. As per the guidance from the developers, these scripts should only be able to refer to the origin from which the protected document is being served.

Now you're done with setting up the script directive!

As an independent exercise without further guidance from us, add a new directive to this policy for your allowed connections.

When you're done, you should have the following policy

Before saving the policy, we need to set the action. As Acme Corp wants to enforce the CSP immediately, set the action to Allow. This will allow only the selected scripts in the policy to the be loaded on the browser.

Once you're done, hit Save.

Now head over to your page (https://*.cfdemolab.xyz/contact/received). Right click and select Inspect.

You will then see the developer tools tab pop up. Head over to Console.

Here you can see that the policies have been enforced and no other scripts can be loaded other than what has been specified.

Now heading back to the dashboard, you can observe these policy violations. This is helpful to understand the top active resources that violate your policy and evaluate if the policy needs to be adjusted.

Done!

We have explored a pre-configured web application with third-party scripts running and configured security policies from scratch.

When you are finished this task, you have finished the labs. Congratulations!