How to avoid payload manipulation on reference qualifier.

[Tae Kyung Lee]

Hello.

Reference qualifiers are our old friend and used in many where in ServiceNow, especially with catalog items variable for filtering choice list.

But when users expand choice list, internal request '/angular.do?sysparm_type=sp_ref_list_data' will be fired with non-encoded/encrypted payload like below.

The problem is that this payload can be manipulated and posted again freely.

So if someone wants to get unauthorized data, he can do it especially with manipulated 'requested_for' that can get easily in ServiceNow.

Once users get sys_id of important record, they can do many things with that.

Below is the scary result of 'GETTING ALL RECORDS' in asset table by simple modifying payload above.

Of course it is only possible with table that user has proper ACL.

But there are some important tables that open at minimal ACL such as asset(snc_internal), so you have to be careful when use reference qualifier with those tables.

Some company or customer may requires high-leveled secure coding with ServiceNow, 

So there are some workarounds for preventing this kind of manipulation or exposing unauthorized data.

1. Using ACL

  - Most simplest way, but if table is in another scope you can't create proper ACL on that.

2. Using BQ BR or Data filtration

  - Second simplest way, but if table is in global you can't create Query BR or data filtration on that.

3. Converting reference to select_box, then fill it with catalog client script.

  - Select Box does not call '/angular.do?sysparm_type=sp_ref_list_data' so we can avoid payload manipulation.

  - Create client callable script and move conditions in reference qualifier into it so that manipulated payload can be ignored on server-side.

  - Get result with GlideAjax and fill choice list with it in onLoad/onChange catalog client script.

    Codes are like below.

  - Result : when catalog item is loaded, request to instance for filling choice list is like below.

     Of course, sysparm_request still can be manipulated, but it will be ignored in server-side if you developed right:)

If anyone know better solution for this, please share with me!

[Ahana 01]

To avoid payload manipulation on reference qualifiers in ServiceNow, you can follow these steps:

1. Use Server-Side Scripting: Always use server-side scripting for reference qualifiers to prevent payload manipulation. Client-side scripting can be manipulated by users with knowledge of JavaScript.

2. Use Encoded Query Strings: Encoded query strings can be used in reference qualifiers to filter the data that is returned. This can help to prevent payload manipulation.

3. Use GlideRecord Queries: GlideRecord queries can be used in reference qualifiers to filter the data that is returned. This can also help to prevent payload manipulation.

4. Use Access Controls: Access controls can be used to restrict the data that users can view and modify. This can help to prevent payload manipulation.

5. Use Business Rules: Business rules can be used to enforce data integrity and prevent payload manipulation.

6. Use UI Policies: UI policies can be used to control the visibility and read/write access of fields on a form. This can help to prevent payload manipulation.

7. Use Data Policies: Data policies can be used to enforce data integrity and prevent payload manipulation.

8. Use ACLs: Access Control Lists (ACLs) can be used to restrict the data that users can view and modify. This can help to prevent payload manipulation.

9. Use Server-Side Validation: Always validate data on the server-side to prevent payload manipulation. Client-side validation can be bypassed by users with knowledge of JavaScript.

10. Use Secure Coding Practices: Always follow secure coding practices to prevent payload manipulation. This includes validating input, encoding output, and using parameterized queries.

nowKB.com