Securing Legacy system Properties - Support and Troubleshooting

Securing Legacy system Properties Summary Table of Contents What system properties are being secured and why? What action is required from our customers? FAQs What happens if instance owners don't take action? How long do customers have to make their changes? Will the maintenance be performed on the sub-prod instances first? Can I opt out? How can I test? What system properties are being secured and why? These glide properties may negatively impact the security posture of the instance if set to an insecure value. We are contacting customers impacted by these properties directly. Here is the list of properties with a short description of their function: Property Name Secure Value Description glide.basicauth.required.schema glide.basicauth.required.soap glide.basicauth.required.wsdl glide.basicauth.required.rss glide.basicauth.required.scriptedprocessor glide.basicauth.required.api glide.basicauth.required.jsonv2 glide.basicauth.required.unl glide.basicauth.required.xml glide.basicauth.required.importprocessor glide.basicauth.required.xmloutputprocessor glide.basicauth.required.csv glide.basicauth.required.excel glide.basicauth.required.pdf glide.basicauth.required.xsd

true The set of glide.basicauth.required.* properties impact authentication. If a property is not set to "true", the respective mechanism, such as SOAP or WSDL, does not require authentication on all inbound connections. This can lead to unauthenticated access to sensitive content/data on the platform. glide.security.strict.updates true When set to "true", this property adds a layer of verification by verifying a given user has the appropriate ACL to update the form on form submission or field update. glide.security.sandbox_no_unsafe_methods true When set to "true", this property prevents dangerous methods from being run in the javascript sandbox on a Now instance. An insecure setting for this property could allow users to run commands beyond the intended instance scope. NOTE: If this property is not visible, it is in a secure state by default and no update is needed. glide.ui.escape_text true The property glide.ui.escape_text, when set to "true", escapes XML values at the parser level for the user interface. A secure setting prevents reflected and stored cross-site scripting attacks. If "glide.ui.escape_text" is not set to the recommended value of "true", then XML values will not be escaped at the parser level for the user interface; this will leave jelly templates susceptible to reflected and stored cross-site scripting (XSS) attacks. glide.ui.security.codetag.allow_script false If "glide.ui.security.codetag.allow_script" is not set to the recommended value of "false", then rendered HTML is allowed in journal fields and forms. This can lead to cross-site scripting (XSS) attacks when malicious HTML is inserted between code tags. If the customer does not take action, we will change the settings to a secure state for them via maintenance (write audits) (Does not apply to self hosted/on-prem customers) Identify which properties need to be changed by running the following background script. Navigate to /sys.scripts.do and run the script. /* Run this script to identify the legacy system properties in an insecure state */ insecure_values_list = []; secure_values = {'glide.basicauth.required.schema':'true', 'glide.basicauth.required.soap': 'true', 'glide.basicauth.required.wsdl': 'true', 'glide.basicauth.required.rss':'true', 'glide.basicauth.required.scriptedprocessor':'true', 'glide.basicauth.required.api':'true', 'glide.basicauth.required.jsonv2':'true', 'glide.basicauth.required.unl':'true', 'glide.basicauth.required.xml':'true', 'glide.basicauth.required.importprocessor':'true', 'glide.basicauth.required.xmloutputprocessor':'true', 'glide.basicauth.required.csv':'true', 'glide.basicauth.required.excel':'true', 'glide.basicauth.required.pdf':'true', 'glide.basicauth.required.xsd':'true', 'glide.security.strict.updates':'true', 'glide.security.sandbox_no_unsafe_methods':'true', 'glide.ui.escape_text':'true', 'glide.ui.security.codetag.allow_script': 'false'} secure_if_property_does_not_exist = "glide.security.sandbox_no_unsafe_methods";

for (property in secure_values) { is_in_secure_state(property); }

gs.print("Change the following properties in the sys_properties table to the corresponding secure value. If the property does not exist in the table, add the property.")

for (property in insecure_values_list){ gs.print("Insecure property: " + insecure_values_list[property] + " , Set the value to " + secure_values[insecure_values_list[property]].toString()); }

What action is required from our customers? We would like you to revert these system properties to the safe values in your sub-prod instances, test and confirm if any of your services are affected, and then push these changes to your production environment. ServiceNOW's best practice would be to push these updates across your platform via Update Sets. The steps are as follows: 1) Create new update set in your sub-prod instance 2) Capture changes to your system properties in the update set. 3) Push update set to any other sub-prod instances for testing. 4) Once confirmed everything is working and has been thoroughly tested, we recommend pushing the update set to your production instance. Here is some documentation about update sets and properties that may help: https://docs.servicenow.com/en-US/bundle/tokyo-application-development/page/build/system-update-sets/concept/system-update-sets.html https://docs.servicenow.com/bundle/tokyo-platform-administration/page/administer/reference-pages/task/t_AddAPropertyUsingSysPropsList.html ServiceNOW strongly advises following this plan as soon as possible to give you enough time to test and fix any issues than waiting for the write audit which will not allow you to revert the settings back to unsafe values. FAQs What happens if instance owners don't take action? (Does not apply to self hosted/on-prem customers) If an instance owner does not take action, we will set the settings to a secure state via scheduled instance maintenance. You will be notified of the date and time for the maintenance. How long do customers have to make their changes? (Does not apply to self hosted/on-prem customers) We give customers 60 days from the first comms record to make the changes. Will the maintenance be performed on the sub-prod instances first? (Does not apply to self hosted/on-prem customers) Yes in the communication sent to instance owners, we will outline the dates and times for the scheduled sub-prod maintenance. The instances in question will be listed in your communication record. You will then have before the maintenance is performed on the production instance(s). Can I opt out? (Does not apply to self hosted/on-prem customers) No. These properties must be set to a secure value. How can I test? glide.basicauth.required.* Identify customer-maintained inbound integrations into the instance. Verify the ServiceNow connection is configured with credentials in the other system. Correct the properties and test the integration. glide.security.strict.updates Correct the property and validate that customer-maintained ACLs are configured to allow users to submit intended forms. glide.security.sandbox_no_unsafe_methods Correct the property and monitor the syslog table for "GlideSystem: Security prevented execution of" warnings during supported operations of customer-maintained script. glide.ui.escape_text Correct the property and identify customer-maintained records within the sys_ui_page table, and sys_dictionary_list table where Type=html and Display=true. Confirm that customer-maintained Jelly script within HTML fields do not functionally rely on displaying XML markup input by a user. glide.ui.security.codetag.allow_script Correct the property and validate that Javascript is not operationally used via codetags within comments or work note journal entries.