Client Protection

About Client Protection

In today’s digital landscape, safeguarding sensitive information and ensuring the integrity of web-based systems are essential for maintaining client trust and complying with security mandates. Web Application Firewalls (WAFs) provide critical protections by monitoring and controlling incoming and outgoing traffic based on predefined security rules. Specifically, WAF controls like Page Integrity and Content Security Policy (CSP) are designed to meet key security requirements, addressing vulnerabilities during system development and detecting unauthorized changes. These controls are particularly important for organizations that must comply with standards like PCI DSS 4.0.

Addressing PCI DSS 4.0 requirements with WAF controls

In the context of PCI DSS 4.0 compliance, web application firewalls (WAFs) play a crucial role in securing sensitive data and maintaining the integrity of online environments. Two key WAF controls—Page Integrity and Content Security Policy (CSP)—specifically address important compliance requirements outlined in sections 6.4.3 and 11.6.1 of the standard.

Page Integrity focuses on fulfilling the requirements of PCI DSS 6.4.3, which mandates that security risks be identified and mitigated during system development and changes. This control helps ensure that any changes to a webpage, whether during development or post-deployment, are thoroughly validated and secure. By ensuring that web pages and their content are delivered without unauthorized changes, this control supports organizations in preventing vulnerabilities introduced by unvetted modifications.

On the other hand, a combination of the Page Integrity and Content Security Policy (CSP) controls address PCI DSS 11.6.1, which requires the detection of unauthorized changes to critical files and resources. In addition to Page Integrity preventing and detecting changes and additions, CSP works by restricting the types of content that can be executed on a webpage, thus preventing malicious scripts and unauthorized modifications from being executed. By alerting and blocking such activities, CSP enhances the detection and response capabilities necessary to maintain a secure environment.

Relevance of PCI DSS 6.4.3 and 11.6.1 to broader security mandates

While PCI DSS 4.0 is specifically tailored for organizations handling payment card data, the principles underlying Requirements 6.4.3 and 11.6.1 are highly relevant across a variety of other security frameworks and compliance mandates. Both requirements address core aspects of secure development, change management, and file integrity monitoring—key components in maintaining a robust security posture, regardless of the specific regulatory landscape.

Requirement 6.4.3, which focuses on risk management during system development and changes, mirrors guidelines in other security standards such as ISO/IEC 27001 and the NIST Cybersecurity Framework. These standards also emphasize the importance of ensuring that system updates and changes do not introduce vulnerabilities or weaken security defenses. Similarly, secure software development and deployment are foundational aspects of the General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HIPAA), where protecting sensitive personal data is paramount.

Requirement 11.6.1, with its focus on monitoring for unauthorized changes, aligns with security controls across various frameworks, such as CIS Controls and SOX (Sarbanes-Oxley Act), which mandate continuous monitoring and detection of file integrity issues. The need to detect and respond to unauthorized modifications is critical not just for PCI compliance, but for safeguarding any kind of sensitive data, including financial, healthcare, and personally identifiable information (PII).

Client Protection with Fortra Managed WAF

Complete and PCI DSS 4.0 compliant Client Protection is achieved by a combination of the two controls Page Integrity and Content Security Policy. For protected pages the Content Security Policy module supplements the Page Integrity module by controlling execution of inline active content.

• Page Integrity

  1. Injects proprietary javascript in server responses that maps and collects information about active content

  2. Detects changes to authorized active content and prevents execution on protected pages

  3. Detects new active content requiring authorization

  4. Interacts with client browsers’ SRI (Sub Resource Integrity) and CSP (Content Security Policy) features to map and track changes to active content that gets loaded in the client’s browser on protected pages

  5. Injects integrity checksums in tags loading external content which the browser Sub Resource Integrity function uses to validate that the content loaded from external source is the same as what was authorized

  6. Injects cryptographic nonces into inline javascript on protected pages which interacts with the browser Content Security Policy function to prevent non-authorized / changed scripts from being executed on protected pages

  7. Provides an interface for management’s required approval and authorization

  8. Detects and reports integrity violations for authorized content

• Content Security Policy

  1. Detects and prevents non-authorized inline active content from execution on protected pages and reports violations

  2. Maps CSP relevant information required to build a Content Security Policy for the entire website/application that gets enforced by the client’s browser

  3. Detects and reports violations of the Content Security Policy

Configuring Client Protection

To configure Client Protection for pages that require protection from unauthorized / hostile active content that’s loaded from external sources – 1st party as well as 3rd party content:

1. Configure page integrity

   1. Enable module

   2. Add pages to protect

   3. Wait for module to crowd source active content from client browsers

   4. Review and authorize active content

   5. For each protected page, enable “Report” to enable logging violations in deny log

To further limit execution by type and source and to control execution of inline scripts, the Content Security Policy must be enabled and configured to add protection from unauthorized inline active content – most notably reflected and stored XSS.

The Content Security Policy module will map content and sources for the entire website/application in addition to controlling execution of inline content on protected pages.

1. Configure Content Security Policy

   1. Enable module

   2. Set Operating Mode to “Report only (learn)”

   3. Toggle options as required

   4. Wait for module to crowd source CSP relevant data from client browsers

   5. Review and approve collected data

   6. Review the resulting Content Security Policy header (PENDING) and promote to ACTIVE as it nears completion

   7. Wait to see if client browsers report authorized elements, approve as needed and promote PENDING to ACTIVE

   8. When all authorized elements are allowed, change Operating Mode to “Enforce” – violations will be logged to the deny log

Page Integrity

The Page Integrity module interacts with modern client browsers to crowd source active content and prevent unauthorized modifications to approved content from being executed on protected pages.

For background and integration with the Content Security Policy module see section “Client Protection” above.

Execution of content that is loaded from internal/external sources – that is: all non-inline content – is controlled using the Sub Resource Integrity (SRI) function of modern browsers. For each loaded item a cryptographic checksum of the script content is calculated and when the item is authorized this checksum is injected in the tag that loads the script. The browser SRI function uses this integrity checksum to validate the script item. If the script fails integrity validation the browser will refuse to execute it and report the condition to the WAF.

Execution of inline javascript is controlled using Content Security Policy functionality – allowing only content identified by a nonce to be executed. Inline active content is identified and authorized by a checksum that is calculated by the WAF each time the page containing the inline script is loaded. If the checksum corresponds to an authorized inline script, a random nonce is injected in the script tag and added to the allowed list in the CSP header.

Building and configuring protection for pages

The goal of configuring protection is twofold:

1. Mapping and authorizing active content

2. Preventing unauthorized changes to active content from being executed in the client browser

Once active content is approved and authorized, integrity validation checksums for that content are injected in protected pages. When the page is loaded in the browser the Sub Resource Integrity function validates the integrity of the content using the injected checksums. Content that fails validation is not executed and triggers an alarm being reported to the WAF.

Content that is not yet authorized will not have integrity checksums injected and thus will be allowed to run. This content will be listed as unauthorized in the Resource Integrity Definitions list.

For a page to be fully protected all active content in the list of Resource Integrity Definitions should be in the state “Authorized”.

Managing changes to active content

Content in the Resource Integrity Definitions list is tracked and integrity validated by URL. This implies that if authorized content is changed without the URL changing, it will fail integrity validation and consequently not be executed in the client browser.

To ensure that changed content will not be prevented from executing either the URL to the content must change – for instance by adding a query parameter like ?version=2 to the URL loading the content – or by temporarily toggling authorization to “Unauthorized”, changing the resource, refreshing the resource to re-calculate the integrity checksum, and then re-authorize.

Protected URI paths

The “Protected URI paths” is the list of pages (URI Paths) to protect. In the context of PCI DSS 4.0 - 6.4.3, this will be the list of URI paths – or a regular expression covering multiple paths - that take payment data input. In a wider context this will be URI paths that take confidential data as input.

Parameter exclusion list

Depending on the design of the application generating/inserting links to external content parameters – such as “version=45”, or even an epoch time stamp - may be added to the URL path. Often, the script that gets loaded does not change with these parameters and thus won’t fail the integrity check. However, unless those parameters are removed from the URL path, the script will be mapped as new, unauthorized content, because the URL is unique.

In cases where the script does not change such parameters can be added to the exclusion list which will cause them to be stripped from the mapped and validated URL.

Resource Integrity definitions

The “Resource Integrity definitions” table lists active content that’s executed in the client browser and provides controls to manage and authorize content.

Once the protected URI Paths regular expression patterns have been configured, the module enabled, and settings applied – a script component will be injected in pages that match the protected pages pattern. The script reports active content that’s loaded in the client browser on the protected pages.

The resulting content is listed in the “Resource Integrity definitions” table.

Logging violations

Integrity violations – authorized resources failing integrity validation – are logged to the Website deny log.

Since integrity violations have the potential to be triggered by all client browsers loading the protected page – especially in the case of false positives triggered by changes not following the approval and authorization process – logging is limited to select violations to balance risk of log fatigue with uniqueness and accuracy of logging.

Sub Resource Integrity (SRI)

This section provides a general overview of the Sub Resource Integrity feature that the WAF Page Integrity feature configures and interacts with.

Sub Resource Integrity (SRI) is a browser security feature that ensures that resources loaded by a webpage (such as scripts or styles) have not been tampered with. SRI allows a website to specify a cryptographic hash that the browser uses to verify the integrity of a resource. If the resource's actual hash does not match the one specified, the browser blocks the resource from loading, preventing potential security risks from altered or malicious content.

How Sub Resource Integrity works

Hashing resources

To use SRI, a cryptographic hash (SHA-256, SHA-384, or SHA-512) of the resource's content is generated. This hash is then included in the `integrity` attribute of the resource's HTML tag. The browser uses this hash to check whether the resource was modified after being published.

Resource verification

When a browser requests a resource (such as a JavaScript file or CSS), it calculates the resource's hash. If the computed hash matches the hash provided in the `integrity` attribute, the resource is considered secure and is loaded. If the hash differs, the browser blocks the resource from being loaded, preventing the execution of potentially malicious or altered content.

Usage in HTML

The `integrity` attribute is added to the HTML tags for scripts or styles. It typically looks like this:

```html

<script src="https://example.com/script.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GhM8X07C/m7/wzbD8fjtM4as6W9Q+" crossorigin="anonymous"></script>

```

This example ensures that the browser only loads the script if it matches the provided hash.

Benefits of Sub Resource Integrity

Protection from CDN compromises

If a resource is hosted on a third-party server, such as a Content Delivery Network (CDN), SRI helps protect against CDN compromises where an attacker may replace legitimate resources with malicious ones. SRI ensures that only the original resource can be loaded, as any modification would cause the hash verification to fail.

Preventing malicious modifications

SRI prevents any unauthorized changes to external resources. This helps protect against "man-in-the-middle" attacks or modifications that could occur during transmission over the network.

Cross-origin requests and SRI

When using SRI for cross-origin resources (e.g., scripts from third-party servers), it is important to include the `crossorigin="anonymous"` attribute in the resource tag. This allows the browser to perform the integrity check without sending credentials (such as cookies) to the third-party server, enhancing privacy and security.

Limitations of Sub Resource Integrity

Dynamic content

SRI only works with static resources, such as fixed files hosted on a server. It cannot be used for dynamically generated content, as the hash would change every time the resource is modified.

Browser support

While SRI is supported by most modern browsers, some older browsers may not support the feature. However, in such cases, the resources will still load without SRI verification, leaving them vulnerable to potential tampering.

Content Security Policy

Content Security Policy (CSP) is a security standard introduced by web browsers to help prevent various types of code injection attacks. It acts as a layer of defence by specifying which sources of content, such as scripts, styles, images, and more, are allowed to be executed or loaded on a web page. By defining a strict security policy, web administrators can block malicious content from untrusted sources, ensuring that only content explicitly approved by the developer is executed.

CSP works by defining a set of rules in the HTTP headers or HTML meta tags of a website. These rules specify which sources of content are trusted, such as scripts, styles, and media. When the browser loads the page, it checks each piece of content against the policy. If the content’s source is not allowed by the policy, the browser blocks its execution or display. Additionally, CSP can be configured to report violations, providing administrators with valuable insights into potential threats and attacks.

Fortra Managed WAF can enhance the deployment of CSP by automating the process of policy generation. It analyses traffic and content served by the protected web application, identifying all the resources loaded on the website. By mapping this content, it helps create a comprehensive CSP that accurately reflects the website’s needs, minimizing manual configuration errors. Additionally, it detects changes and enables easily updating the CSP as content changes over time, ensuring that new trusted resources are included and minimizing potential blocking of legitimate content. This integration between a Fortra Managed WAF and CSP not only strengthens security but also streamlines the process of policy management.

For completeness of Client Protection, the Content Security Module integrates with the Page Integrity module for violation reporting and preventing unauthorized inline script content from execution.

The Content Security Policy is comprised of three sections:

1. Operating Mode

   Log or block violations

2. ACTIVE Content Security Policy

   The Content Security Policy currently being inserted in server responses

3. PENDING Content Security Policy

   The Content Security Policy being built

CSP building and configuration

Operating mode

Set CSP operating mode – “log mode” (report-only/learn mode) or “block mode” (enforcement mode).

In log mode, CSP does not block any content but logs violations in the browser's console or sends violation reports to a specified URL. This mode is ideal for testing and tuning your CSP without risking functionality issues on the site.

In block mode, CSP actively blocks content that violates the policy. This ensures that no unapproved scripts, styles, or other resources are executed, providing strong protection against attacks like cross-site scripting (XSS).

ACTIVE Content Security Policy

Displays the ACTIVE Content Security Policy being served by the WAF (if enabled).

PENDING Content Security Policy

Displays the PENDING Content Security Policy options.

Options (Recommended)

Toggle options that are considered safe (enough).

Options (Unsafe)

Toggle options that are not considered safe.

Whitelisted domains

Content from whitelisted domains is automatically considered safe and allowed based on origin. In the list of discovered content this content will be automatically flagged as “Allow (settings)” and thus be included in the autogenerated (calculated/proposed) CSP header.

Resulting Content Security Policy

Displays the resulting Content Security Policy based on allowed elements and selected policy options. This policy is also referred to as PENDING.

Content Security Policy elements

The CSP header is built based on client reported and manually added elements (if any).

While still in “Report Only (learn)” mode, overly restrictive CSP headers are set to make clients report all content that can be controlled using CSP headers. This content is listed in the Client Reported Content table for authorization (Allow) – either by changing settings, adding whitelisted domain names, or by enabling more general options.

Once content is authorized/allowed the “Calculated CSP header” reflects the changes and the content line in the table changes colour to either green or blue depending on being allowed by User or Settings respectively.

When in block mode the Content Security Policy Elements table will mostly contain violations (if any), which can either be caused by unauthorized changes to server pages (changes not following change management procedures) or by actual violations.

Elements are listed in the “Content Security Policy Elements” table. Columns with sort symbol appended to name can be selected as sort keys by clicking the column header.

CSP elements table options

Logging violations

When Content Security Policy Operating Mode is changed to Enforcing, CSP violations are logged to the Website deny log.

Since CSP violations have the potential to be triggered by all client browsers loading the page triggering the violation – especially in the case of false positives triggered by changes not following web application change release procedures – logging is limited to select violations to balance risk of log fatigue with uniqueness and accuracy of logging.

Content Security Policy (CSP)

This section provides a general overview of the browser Content Security Policy feature that the WAF configures and interacts with.

Content Security Policy (CSP) is a security feature implemented in modern web browsers that helps prevent various types of attacks, such as Cross-Site Scripting (XSS) and data injection attacks. It allows web developers to specify which sources of content are considered safe for their web pages. By defining a set of rules for what resources (scripts, styles, images, etc.) can be loaded and executed, CSP reduces the risk of an attacker injecting malicious content into a webpage.

How Content Security Policy works

CSP directive in HTTP response headers

A CSP policy is delivered to the browser through HTTP response headers, most commonly in the Content-Security-Policy header. These headers instruct the browser on what resources should be allowed and from which sources they can be loaded.

CSP directives

The CSP consists of various directives that control specific aspects of the webpage’s behavior. For example, default-src controls all resources, script-src controls JavaScript loading, and img-src defines allowed image sources.

Source expressions

Each directive is followed by source expressions that define where the browser can load specific content from. Some common examples include 'self', 'none', and trusted URLs.

Blocking or reporting

CSP can operate in enforcement mode (blocking unauthorized content) or reporting mode (logging violations for analysis). In reporting mode, violations can be sent to a specified report URI.

Inline script protection

CSP helps mitigate the risks of inline scripts. It can block inline scripts unless explicitly allowed with nonces or hashes.

Mitigating XSS attacks

CSP is designed to mitigate XSS attacks by allowing only scripts from trusted sources and blocking those injected by attackers.

CSP Modes: Log or Block

• Log Mode: Logs violations without blocking content. Helps fine-tune the policy without affecting user experience.

• Block Mode: Blocks unauthorized content, providing stronger security but potentially breaking functionality if the policy is not carefully tested.