Query ACLs

[Anurag Tripathi]

This Article dives into the new Access Control List (ACL) types introduced by ServiceNow: Query_Match & Query_Range. It addresses a critical vulnerability related to information leakage through query manipulation and explains how these ACLs enhance data security.

Let's take a look what these are and more importantly why was it necessary.

Issue: Information Leakage Through Query Manipulation

Consider a situation where users can access the user table but shouldn't see sensitive fields. Field-level ACLs are in place to hide fields like "Salary" and "SSN." However, a malicious user might try to infer information using queries:

SSN Starts With "2": The user queries for all users with an SSN starting with "2." Even if the SSN field is hidden, the user can still see other accessible columns (e.g., name) and the number of matching records. This reveals that there are, for example, 50 users with SSNs starting with "2."

Salary More Than 100K: The user queries for all users with a salary greater than $100,000. Even if the salary field is hidden, the query results can show a list of user names who meet this criterion, indirectly revealing salary information.

Impact: This type of information leakage can compromise data security, as users can gain insights into sensitive data without directly accessing it.

ServiceNow's Solution: Query ACLs

To address this vulnerability, ServiceNow introduced Query ACLs. These ACLs are designed to restrict the ability to run queries on columns for which the user has limited or no access.

How is this implemented.

Query_Match ACL:

Purpose: Restricts queries that require exact and complete information to run.

Functionality: Query_Match ACLs are applied to fields containing sensitive data. They ensure that users must provide the full, correct value to retrieve any data.

Example: Suppose you have a Query_Match ACL on the "SSN" field. A user can only retrieve a specific user's record if they know the exact SSN. They cannot use partial values or wildcards.

Query_Range ACL:

Purpose: Restricts queries that use ranges, wildcards, or partial values.

Functionality: Query_Range ACLs prevent users from querying for values within a certain range or pattern, which could indirectly reveal sensitive information.

Example: If a Query_Range ACL is applied to the "Salary" field, users cannot query for salaries greater than $100,000 or within a specific range. They can only retrieve records if they know the exact salary value.

Default Behaviour: Query ACLs default to a *.* ACL, granting read access unless specified otherwise.

Reviewing Recent Changes:

ServiceNow has made significant changes to ACLs as part of this security enhancement. You can review these changes in your instance using the following URL (replace <INSTANCE_NAME> with your instance URL):

https://<INSTANCE_NAME>.service-now.com/sys_metadata_list.do?sysparm_query=sys_updated_bySTARTSWITH@... 

When should you use Query ACLs:

Sensitive Data: Implement Query ACLs for sensitive data that requires protection from unauthorized access.

Partial Access: Use Query ACLs when users have partial access to rows or columns and there is a risk of information leakage through query manipulation.

Data Filters: Query ACLs are essential when access is not adequately enforced by data filters.

Usage and Examples

Problem 1: A user should only be able to view the email address of other users if they know the exact email address. How would you configure this?

Solution: Create a Query_Match ACL on the email field of the sys_user table. This ensures that a user must provide the exact email address to retrieve the record.

Problem 2: You need to prevent users from querying salaries within a specific range. How would you configure this?

Solution: Create a Query_Range ACL on the salary field. This will prevent users from querying for salaries within a certain range, preventing them from inferring salary information.

Useful Articles and links

• Troubleshooting query_range ACLs
• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2046494
• Query ACLs Product Documentation

[GoBucks]

@Anurag TripathiThanks for this summary.  I had been reading through ServiceNow's KB2046494 myself and struggling to arrive at what our specific actions items actually need to be, as a result of the maintenance.  That KBA is a bit overwhelming at first, if not a bit confusing too.  The maintenance performed was definitely a big one as seen by going to the sys_metadata URL you provided above.

[Anurag Tripathi]

@GoBucks 

Yes there is a lot of information there. In my case there were a few reports of things that stopped working so we looked at it case by case(mostly Left Nav and reports that stopped working because they had Filters using STARTS With/Contains etc). There is no point updating 21K ACLs and that would also defeat the purpose of having this ACLs added to the platform. 

If you get a hi case, they can provide you with a script that logs all the Query ACL Denys on your platform, it generates a log file that can be downloaded form a node. I haven't used the script (yet). But if you get that , that could your list of actionable items.

[wamiqmax]

Great blog, easy to understand.
Did SN by default provided these ACLs over all field level ACLs written(At least for ones which were OOTB) OR we need to implement them?

[milenapsako]

Hi guys, please can you paste the content of KB here ? I'm not able to open it. Many thanks.

[Anurag Tripathi]

@wamiqmax ServiceNow has added a lot of ACLS based on where they saw usiers having partial access to tables.

But going forward you have to add it.

[guptaprashant]

@Anurag Tripathi Thanks for the blog as KB seems quite overwhelming. I validated the steps mentioned in the article, but little confused whether it is required to run the script include?

[Anurag Tripathi]

You don't need to run it , its more for information if you need to investigate what all actions that were working before will be denied now.

[roy dreijling]

Very strange. I would expect if a user does not have read access to a field, they can also not query on it.

This would be a lot easier to manage.

[SANDEEP28]

@Anurag Tripathi I have one query. I added read  field level ACL on personal Email address field on HR profile Table. User is not able to see the field in List view now, which is expected. As a user, when I tried altering query in browser URL then it gave me below error

"Part of the query on sn_hr_core_profile has been ignored because of insufficient access for 'query_match' operation on sn_hr_core" .

I checked there in no "query_match" ACL on HR profile table. Does ServiceNow by default applied "Query_match" ACL for field level ACLs?

[cj9r]

@SANDEEP28 You probably already figured this out, but saw your message and wanted to add that you need to look at *.* query_match ACL.  This was modified in May update and if you don't have a query_match ACL configured on the HR profile Table, ACL evaluation will continue through the algorithm until it hits this *.* ACL, which basically enforces Role = Public and Security Attribute Condition HasRightsToReadIsTrue.