The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

Defense in Depth

As always, a robust approach to security should employ defense-in-depth

measures to provide additional protection in the event that front-line defenses

fail for any reason. In the context of attacks against back-end databases, there

are three layers of further defense that can be employed:

■■

The application should use the lowest possible level of privileges when

accessing the database. In general, the application does not need DBA-

level permissions — it normally only needs to read and write its own

data. In security-critical situations, the application may employ a differ-

ent database account for performing different actions. For example, if

90% of its database queries only require read access, then these can be

performed using an account which does not have write privileges. If a

particular query only needs to read a subset of data (for example, the

orders table, but not the user accounts table), then an account with the

corresponding level of access can be used. If this approach is enforced

throughout the application, then any residual SQL injection flaws that

may exist are likely to have their impact significantly reduced.

■■

Many enterprise databases include a huge amount of default function-

ality that can be leveraged by an attacker who gains the ability to 

execute arbitrary SQL statements. Wherever possible, unnecessary

functions should be removed or disabled. Even though there are cases

where a skilled and determined attacker may be able to recreate some

required functions through other means, this task is not usually

straightforward, and the database hardening will still place significant

obstacles in the way of the attacker.

■■

All vendor-issued security patches should be evaluated, tested, and

applied in a timely way, to fix known vulnerabilities within the database

software itself. In security-critical situations, database administrators can