Cross-site scripting occurs when an attacker injects malicious JavaScript into an entry point and the platform/application fails to escape the malicious JavaScript before transmitting it to the victim's browser for execution. The glide.ui.escape_text property, when enabled, escapes the XML values at parser level before transmitting it to client's browser.
Escaping ensures that browsers do not parse the malicious JavaScript embedded in untrusted data as JavaScript and execute it. A malicious user may try XSS attack to either hijack other users' session or redirect the user to a malicious website. ServiceNow has an implementation in place to secure cookies, but escaping it relies on this property to be set to true.
Requirement
Mandatory
Recommended Value
True
Default Behavior
Set to true
Revertible behavior
N/A
Role required
Security_admin
Release Version
2011 June
Functional Impact
(Medium) This remediation would enforce XML encoding to occur on the UI at the XML parser level thus rendering back encoded results to the user. This can have a functionality impact based on the instance user interaction with the resulted data.
Security Risk
(High) Input validation has to occur on the application to defend against cross-site scripting attacks which would allow foreign scripts to execute on user session in the logged in browser's context. This can be leveraged by attackers to steal session information and sensitive data.
Workaround
After property set to true, Service Now stops rendering HTML tags written in description of catalog item or HTML tags in help text of catalog item variable. You may not be able to use HTML formatting for some fields.
However, some customers require glide.ui.escape_text property to be turned off. When this is the case, all JEXL expressions would be prefixed with an output encoder as shown below:
During SOAP web service calls/requests made against the tables to perform any CREATE, READ, UPDATE or DELETE operation, the glide.soap.strict_security property enforces web service security using a combination of basic authentication challenge/response over the HTTP protocol and system level access control using the Contextual Security.
If this property is set to true, the following actions are performed:
Check incoming SOAP request for role authorization to validate if the user has appropriate role to perform the operation
Check the system-level ACLs while retrieving data in the form of SOAP data on the table
Check the field-level ACLs for any CRUD operation performed against a field of table
Ensure security ACLs are checked and validated even when the records are accessed through SOAP calls
Requirement
Mandatory
Recommended Value
True
Default Behavior
Set to true
Revertible behavior
N/A
Role required
Security_admin
Release Version
Summer 2008
Functional Impact
(High) This remediation enforces the system-level access control while retrieving data from tables/pages in the form of SOAP data on the instance. If there are users currently accessing this data, they are restricted/allowed to access the data based on the ACL rules. For the default roles that have access to the SOAP data, see SOAP Roles.
Security Risk
(High) Without appropriate authorization configured on the incoming SOAP requests, an unauthorized user can get access to sensitive content/data on the target instance.
The glide.ui.escape_all_script property, when set to true, forces all scripts injected in Jelly to be escaped by default. It escapes all the JS and HTML strings included within <j:jelly> ... </j:jelly> before being written to the output stream and prevents a number of XSS issues.
If the property is not set to true, then to prevent XSS, developers have to go through an exercise for each custom Jelly script, locate the Jelly variables that are being sent to output stream to render on the webpage, and perform escaping on each of those using the following tags:
${JS:expression}
${HTML:expression}
OR
${JS,HTML:expression}
Requirement
Mandatory
Recommended Value
True
Default Behavior
Set to true
Revertible behavior
N/A
Role required
Security_admin
Release Version
2011 October
Functional Impact
(Medium) This remediation enforces Jelly escaping at the parser level, thus rendering back encoded results to the user. This can have a functionality impact based on the instance user interaction with the resulted data.
Security Risk
(High) Input validation has to occur on all the user input being entered on the application. By doing so, injection attacks against the platform can be defended and protected.
Workaround
The UI may be affected as some of the scripts and HTML tags designed to be rendered on a webpage may seem to be broken. This remediation sends the output encoded page to the browser to render. For example, instead of 'my string here ', it might display '<u>my string here</u> as the <u> tag was properly escaped.
In that case, to prevent escaping add NOESC prefix to Jelly expression in order to prevent JS escaping. For example,
The system property glide.ui.escape_html_list_field escapes HTML for HTML fields in a list view. HTML is one of the types that can be assigned to the dictionary fields. Assigning "HTML" fields to any field type provides functionality to the user to format the content using HTML codes (for example, <p>,<a href>,<b>,<font>,<img> etc.). When you see the table list (for example, /problem_list.do) or view the list of records, these HTML formatted fields may appear if that column is selected in a list view and if this property is set to false.
A malicious user can inject HTML code within the form field to execute unwanted scripts on different client/user sessions. It is recommended to set this property to true so that HTML escaping is performed before the records/fields are rendered in the browser when the table is displayed as a list view.
To prevent application against cross site scripting attacks
Requirement
Mandatory
Recommended Value
True
Default Behavior
Set to true
Revertible behavior
N/A
Role required
Security_admin
Release Version
Spring 2010
Functional Impact
(Medium) This remediation enforces HTML encoding to occur on the UI at the HTML parser level and thus renders back encoded results to the user. This can have a functionality impact based on the instance user interaction with the resulted data.
Security Risk
(High) Input validation has to occur on the application to defend against cross-site scripting attacks that allow foreign scripts to execute on user session in the logged in browser's context. This can be leveraged by attackers to steal session information and sensitive data.
Workaround
If there is a corporate need to allow users to write HTML formatted input, then a custom business rule should be created to escape certain blacklisted HTML characters or tags that can restrict script execution.
When set to true, the glide.script.use.sandbox property enables script sandboxing. This property belongs to the same family of 2.8 (glide.script.allow.ajaxevaluate) and 3.9 (glide.script.secure.ajaxgliderecord) that secures and restricts execution of scripts originating from the client.
There are two cases within the system that allow the client to send scripts to the server for evaluation:
Filters and/or queries: It is legal to send a filter to the server such as assigned_to=javascript:getMyGroups()
System API: The API call AJAXEvaluate allows the client to run arbitrary scripts on the server and receive a response
If you enable script sandboxing, the script being evaluated at either of these two entry points runs within a reduced rights sandbox with the following characteristics:
Only those business rules marked client callable are available within the sandbox
Only script includes marked client callable are available within the sandbox
Certain API calls (largely, but not entirely, limited to those dealing with direct DB access) are not allowed
Data cannot be inserted, updated, or deleted from within the sandbox - any calls to current.update(), for example, are ignored
If you run the system without script sandboxing enabled, none of these restrictions apply.
Enforces validation for the client-side JavaScript queries that are launched against the platform
Requirement
Mandatory
Recommended Value
True
Default Behavior
Set to true
Revertible behavior
Once changed, it cannot be reverted back
Role required
Security_admin
Release Version
Fall 2009
Functional Impact
(High) This remediation enforce validation for the client-side javascript queries that are launched against the platform. There is a potential impact if customer has customizations that include hard coded JS queries to perform CRUD operations.
Security Risk
(High) The ServiceNow platform provides wide variety of features and functionality through Javascript queries. However, without appropriate authorization and validation, there is a potential for an attacker to perform unauthorized operations against the platform.
The glide.script.allow.ajaxevaluate property belongs to the same family as 2.5 (glide.script.use.sandbox) and 3.9 (glide.script.secure.ajaxgliderecord), that secures and restricts execution of scripts originating from the client. There are two cases within the system that allow the client to send scripts to the server for evaluation:
Filters and/or queries: It is legal to send a filter to the server such as: assigned_to=javascript:getMyGroups().
System API: The API call AJAXEvaluate allows the client to run arbitrary scripts on the server and receive a response.
When this property is set to false, the system does not allow the use of AJAXEvaluate API call from the client script.
Restrict arbitrary client script execution using the system API on the server side
Requirement
Mandatory
Recommended Value
False
Default Behavior
Set to false
Revertible behavior
N/A
Role required
Security_admin
Release Version
Fall 2009
Functional Impact
(Medium) This remediation would enforce AJAEvaluate processor to be turned off and could impact functionality is customer is explicitly using the AJAX evaluate processor as part of any customized scripts. For more information, seeGlideAjax.
Security Risk
(High) AJAXEvaluate can allow arbitrary javascript to execute on the client browser by leveraging the server side objects.
Checks conditions on UI actions before execution. When it is set to true, it will add an extra layer of validation using UI actions on the table before the form gets rendered in the browser.
To ensure an added layer of verification of UI Actions before presenting the form in the browser.
Requirement
Mandatory
Recommended Value
True
Default Behavior
Set to true
Revertible behavior
N/A
Role required
Security_admin
Release Version
Fall 2009
Functional Impact
(Low) This remediation only adds an extra layer of validation to check for UI actions on the target table/page on the instance. As long as the Access controls are set appropriately on the customer instance, there should not be an impact here.
Security Risk
(Medium) Access request should always be checked when transactions happen between two zones. This operation validates any UI actions before the form is rendered to the end user.
Workaround
No alternate method available.
Disabling SSLv2/SSLv3
When active, outbound connections from an instance are forced to use TLS instead of SSL. Setting this property forces the MID Server to use TLS when making outbound connections, such as REST and SOAP requests.
To enforce the use if TLS during all outbound connections from ServiceNow instance.
Requirement
Optional
Recommended Value
True
Default Behavior
Set to true.
Revertible behavior
N/A
Role required
Admin
Release Version
Fuji
Functional Impact
(Medium) This remediation would enforce the usage of TLS protocol version when communicating on HTTPS. If there are devices that customer/users of the instance are using do not support TLS communication, there will be potential outage.
Security Risk
(Medium) Due to a number of Client side attacks such as BEAST, SSL heart-bleed etc, legacy versions of SSL were proven to be insecure when utilized for HTTP secure shell implementation.
