Query ACLs
Summarize
Summary of Query ACLs
Query ACLs (Access Control Lists) provide ServiceNow customers with the ability to implement granular data access controls by defining who can execute specific queries on data. They are essential for protecting sensitive information from unauthorized access, especially in scenarios involving conditional or partial access to data.
Show less
Key Features
- Operation Types: Query ACLs operate using either queryrange or querymatch to control how users can query data.
- Protection Against Attacks: They help defend against blind query attacks by restricting access to sensitive data.
- Conditional Access: Query ACLs should be implemented where access to certain rows or columns is conditional based on user roles or permissions.
- Behavior:
- querymatch: Includes safe operators (e.g., EQUALS, NOTEQUALS) that allow for precise record querying.
- queryrange: Includes riskier operators (e.g., STARTSWITH, CONTAINS) that can be exploited to retrieve broader datasets.
- Default Behavior: When no specific query ACL is defined, a star.star ACL grants read access by default. Defined query ACLs override this behavior.
Key Outcomes
By implementing Query ACLs, ServiceNow customers can ensure that:
- Access to sensitive information is tightly controlled and monitored.
- Users can only perform queries that align with their access rights, enhancing data security.
- Potential vulnerabilities to unauthorized data extraction through broad queries are minimized.
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.
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. Aquery_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_match and query_range operations for secure and granular table
querying behavior. Their behaviors are described below:query_match-
query_matchis composed of: EQUALS, NOT_EQUALS, IN, NOT_IN, SAMEAS, NSAMEAS, ANYTHING, ISEMPTYSTRING, ISEMPTY, ISNOTEMPTY, ISNULL, ISNOTNULL.query_matchis 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_rangeis 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
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.