Privilege Escalation in SQL
Play SQL Labs on this vulnerability with SecureFlag!
In SQL standard authorization, a user’s permissions can be granted or revoked for specific database objects.
In this example, the user with username username is created with the password password.
CREATE USER 'username' IDENTIFIED BY 'password';
And here, read privileges have been granted to the user to read a table with the verb SELECT.
GRANT SELECT ON database.table TO 'username';
When the user issues SQL statements against the database, the SQL authorization will limit the action to only be available on that table.
Granting a write privilege, e.g., UPDATE, would give the user the right to change the table. Access grants to unprivileged users must be carefully designed to apply the principle of least privilege.
Procedures
Ownership of an object is assigned to the person who creates it. Only the object owner and database owner have full access to the object.
SQL Functions and procedures can run with definer rights with the owner’s privileges, as opposed to invoker rights. Defining functions with definer’s rights might open privilege escalation paths to be exploited by malicious invokers.
PL/SQL
In PL/SQL, the DBA grant gives administrative privileges to a user database. The ALL privilege gives all the grants for an object.
PL/SQL functions and procedures can be either AUTHID DEFINER or AUTHID CURRENT_USER to set the definer’s or invoker’s rights. Top-level functions or procedures without an AUTHID clause default to AUTHID DEFINER.
T-SQL
In T-SQL, ALL privilege gives all the grants for an object.
References
MITRE - CWE 285 - Improper Authorization
OWASP Top 10 2021 - Broken Access Control