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):
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
11 Comments
