Filtering all inputs
Prevent invalid data from entering a work object or a work object attachment. Filter and validate input data as thoroughly as possible, including input that is submitted from browser forms, input from service requests (such as email), and input from connector responses. Do not rely on client-side editing, which is in the browser, because a hacker can easily bypass it. Perform validation in your server-side application logic.
Use the following features to validate individual values:
| Individual values | |
| Property types |
|
| Allow lists | Several features let you constrain a property value to one of a fixed list or pattern of values, including the property table edits (local list, field values, class key values) on the General tab in Pega Platform 5.5 and later versions, or the Table Edit tab in earlier releases. |
| Restrictions | Complete the Max Length field for Text, Password or Identifier fields. For example, it is difficult to fit a malicious JavaScript program into a small number of characters. |
| Not declarative | If applicable, select the Cannot be a Declarative Target check box. This option is helpful, because a declarative expression could assemble JavaScript source code. |
| Special properties | Select the Cannot be included as an input field check box if the property is always computed from other values. |
| Validation | Identify an edit input rule and an edit validate rule when possible. Do not accept angle brackets, quotation marks, ampersands, or other special characters in fields unless necessary for a sound business reason. For example, the standard validation rule LetterorDigit limits values to only letters and digits. On the PRPC 5.5 property form, the Max Length and Validate fields are displayed on the Advanced tab. |
| Use map value rules, validation rules, and constraints rules to validate inputs. | |
| To test arriving email attachments or other file attachments for software viruses and malicious JavaScripts, override the extension point activity Data-WorkAttach-File. CallVirusCheck with an activity that calls your third-party virus software. Your activity can call a Java class, or in a Microsoft Windows server, a Dynamic Linked Library routine | |
| Ensure that files that are uploaded from application user workstations and text files processed by a file listener are checked against viruses. | |
| Input filtering is worthwhile even if an application has 100% coverage of output filtering for the HTML that the application sends to a browser. Applications often send output to other systems, rather than to a browser, which could contain a malicious JavaScript function, such as an HTML-rendered email message. Infecting another system, which might belong to another department, a customer, or to a supplier is a security failure that is no less serious than infecting an application user. | |
| Avoid using the URL JavaServer Page (JSP) tag in manually created stream rules. If you must use a URL tag, call the SafeURL JavaScript functions to obfuscate the URL query string. |
Previous topic Understanding cross-site scripting Next topic Filtering HTML and XML outputs