Cross-site scripting

Cross-site scripting

Cross-site scripting (XSS) is a web security vulnerability that allows an attacker to

• compromise the interactions that users have with a vulnerable application
• circumvent the same origin policy, which is designed to segregate different websites from each other.

Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

Cross-Site Scripting attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

Leading practices to avoid cross-site scripting vulnerabilities

Pega Platform™ applications depend on JavaScript functions that are run in a web browser. As a result, application users potentially can be exposed to JavaScript-based cross-site scripting security issues. Cross-site scripting is a client-side code injection attack, in which an attacker can run malicious scripts on a legitimate website or web application. If a malicious or infected site (or user) injects unauthorized JavaScript code into a browser form, execution of that JavaScript, on the same or another browser session, can cause serious security problems, including:

• Hijacking the user session
• Defacing websites
• Introducing worms, bots, or viruses
• Sending spam email

Many JavaScript functions are built into standard text file rules, HTML fragment rules, and HTML Property rules. Additional JavaScript files can be created as part of an application.

Pega Platform includes features and facilities that prevent many security vulnerabilities, and Pegasystems routinely tests for and analyzes potential security issues. However, the many software layers in use (network, email, application server, database, firewalls, and so on) make security an ongoing challenge. The practices described in this article address only one dimension of security, but one that has been heavily exploited when ignored.

Suggested approach

Pega recommends using the following best practices to protect against the most common ways that cross-site scripting (XSS) attacks gain access to a client browser:

• Maintain guardrail compliance (see below).
• Filtering all inputs.
• Filtering HTML and XML outputs.
• PublicAPI methods for XSS filtering.

These practices are always important whether or not your application:

• Is used by unauthenticated users
• Is exposed to a large community or embedded as a web mashup in other applications
• Runs in a less-secure network
• Runs in a less-secure physical environment
• Includes stream rules that are not autogenerated

The best practices and the built-in features of Pega Platform are intended to help you build more secure applications by avoiding specific, well-known vulnerabilities.

Maintain guardrail compliance

In a guardrail-compliant application, application rulesets contain only autogenerated flow actions, autogenerated sections, and autogenerated harness rules. The application might use standard rules that are not autogenerated.

Your application eliminates many potential security vulnerabilities, and is easier to maintain and document, by avoiding custom HTML, custom JavaScript, and custom Java.

For more information, see Security Checklist additional tasks.