Query ACLs

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Query ACLs

    Query ACLs in ServiceNow provide granular control over who can query data by explicitly defining access permissions on queries. They operate with two main types:querymatchandqueryrange, enabling precise restrictions on data access to enhance security, especially against blind query attacks where attackers attempt to extract information by querying data without viewing actual values.

    Show full answer Show less

    When to Use Query ACLs

    • Apply query ACLs on columns containing sensitive information that require partial or conditional access.
    • Implement query ACLs when access to specific rows or columns varies among users and is not sufficiently enforced by data filters.
    • Examples:
      • Payroll: Prevent users from range querying salary data beyond their own record.
      • HR Profiles: Restrict users from querying sensitive fields like SSN for other profiles.

    Query ACL Behavior and Operations

    Query ACLs use two operation types to control query capabilities:

    • querymatch: Supports 'safe operators' such as EQUALS, NOTEQUALS, IN, NOTIN, SAMEAS, ISNULL, etc., which fetch specific records without exposing others. Passing this ACL allows users to submit match-based queries; failure blocks these queries.
    • queryrange: Covers more flexible and potentially risky operators like STARTSWITH, CONTAINS, >=, <=, etc., that allow querying broader record sets by adjusting boundaries. Passing this ACL permits range queries and sorting; failure restricts these capabilities.

    Important Considerations

    • If no query ACL is defined, the system defaults to evaluating standard read access on the column via the star.star ACL.
    • When query ACLs exist, they override default read access during query enforcement.

    By strategically implementing query ACLs, ServiceNow customers can better protect sensitive data, enforce least privilege access, and mitigate risks from unauthorized or blind data queries.

    Query ACLs allow you to define more granular access control by explicitly defining who can query the data.

    What is a query ACL

    A query ACLs have their operation set to either query_range or query_match. Query ACLs allow for more specific control of user queries, restricting or enabling access based on their setup. Query ACLs are powerful tools against blind query attacks, where an attacker blindly queries the data to extract information from results, even when they can't see the values.

    When to use a query ACL

    Wherever a column contains sensitive values, and allows partial/conditional access to data a query ACL should be considered and implemented as necessary based on the sensitivity of the data. Wherever there is a partial/conditional access to rows and their columns in tables, especially where that access is not enforced by data filters, query ACLs should be implemented as necessary based on the sensitivity of the data.

    Note:
    Consider query ACLs when some users have access to some rows or columns and not others .

    Payroll query control

    I can see one row in payroll table with my salary, but there is no reason for me to be able to issue range queries to query users with a salary contained within 2 boundaries. A query_range ACL on salary would prevent me from issuing that query.

    HR query control

    I can see all hr_profiles, but can only see SSN for myself. I have no business querying SSN, and query ACLs should prevent me from running queries against SSN of other hr profiles to try to extract SSN mappings.

    Query ACL behavior

    Query ACLs use query_match and query_range operations for secure and granular table querying behavior. Their behaviors are described below:
    query_match

    query_match is composed of: EQUALS, NOT_EQUALS, IN, NOT_IN, SAMEAS, NSAMEAS, ANYTHING, ISEMPTYSTRING, ISEMPTY, ISNOTEMPTY, ISNULL, ISNOTNULL. query_match is made of the "safe operators", in a sense that they are built to fetch specific record(s), and can't be exploited to return others.

    Evaluation outcome Result
    Pass User can submit match queries
    Fail User will not be able to submit match queries:
    • EQUALS
    • NOT_EQUALS
    • IN
    • NOT_IN
    • SAMEAS
    • NSAMEAS
    • ANYTHING
    • ISEMPTYSTRING
    • ISEMPTY
    • ISNOTEMPTY
    • ISNULL
    • ISNOTNULL
    query_range

    query_range is composed of all the others (STARTS_WITH, CONTAINS, >=, <= etc) which are more dangerous as they allow users to query for more records by adjusting the boundary values.

    Evaluation outcome Result
    Pass User can submit range queries and sorting is unrestricted
    Fail The user will not be able to submit range queries with (STARTS_WITH, CONTAINS, >=, <=, etc. Sorting by column is restricted
    Important:

    Query ACLs (both query_match and query_range) default to a star.star ACL that delegates to read access. This means, where ACLs are enforced on queries, if no query ACL was created then read access to the column is evaluated ; if query ACLs are defined then they override the default behavior.