SQL Injection Attacks and Defense - 2009

396 Chapter 9 • Platform-Level Defenses
context, such as dropping tables or executing operating system commands. It’s important to
remember that even with this mitigating control the attacker may still be able to circumvent
business rules and view the portfolio data of another user.
To determine the permissions assigned to a database login, find its role membership and
remove any unnecessary or privileged roles, such as the public or database administrator role.
Ideally, the login should be a member of one (or possibly more) custom application roles.
A follow-up step is to audit permissions assigned to custom application roles to ensure that
they are locked down appropriately. During a database audit, it is very common to find
unnecessary UPDATE or INSERT permissions assigned to custom application roles
intended for read-only access. These audit and subsequent cleanup steps can be performed
with graphical management tools that often accompany the database server platform or with
SQL via the query console.
Revoke PUBLIC Permissions
Every database server platform has a default role to which every login belongs, usually called
the public role, which has a default set of permissions that includes access to system objects.
Attackers use this default access to query system catalogs to map out database schema and
target the juiciest tables for subsequent querying, such as those storing application login
credentials. The public role is also assigned permission to execute built-in system stored
procedures, packages, and functions used for administrative purposes.
Usually you cannot drop the public role; however, it is recommended that you not grant
additional permissions to the public role, because each database user inherits the permissions
of this role. You should revoke public role permissions from as many system objects as possible.
Additionally, you must revoke superfluous permissions granted to the public role on custom
database objects (such as application tables and stored procedures) unless a justifiable reason
for the permissions exists. If necessary, you should assign database permissions to a custom
role that you can use to grant a default level of access to specific users and groups.
Use Stored Procedures
From a security perspective, you should encapsulate application SQL queries within stored
procedures and grant only EXEC permissions on those objects. All other permissions,
such as SELECT, INSERT, and so on, on the underlying objects can be revoked. In the
event of SQL injection, a least-privileged database login that has only EXECUTE
permissions on application stored procedures makes it more difficult to return arbitrary result
sets to the browser. This does not guarantee safety from SQL injection, as the insecure code
could not lie within the stored procedure itself. Additionally, it may be possible to obtain
result sets via other means, such as with blind SQL injection techniques.