the-web-application-hackers-handbook

Chapter 9 n Attacking Data Stores 325
Beyond SQL Injection: Escalating the Database Attack
A successful exploit of a SQL injection vulnerability often results in total compromise
of all application data. Most applications employ a single account for
all database access and rely on application-layer controls to enforce segregation
of access between different users. Gaining unrestricted use of the application’s
database account results in access to all its data.
You may suppose, therefore, that owning all the application’s data is the
finishing point of a SQL injection attack. However, there are many reasons
why it might be productive to advance your attack further, either by exploiting
a vulnerability within the database itself or by harnessing some of its built-in
functionality to achieve your objectives. Further attacks that can be performed
by escalating the database attack include the following:
n If the database is shared with other applications, you may be able to escalate
privileges within the database and gain access to other applications’ data.
n You may be able to compromise the operating system of the database server.
n You may be able to gain network access to other systems. Typically, the
database server is hosted on a protected network behind several layers
of network perimeter defenses. From the database server, you may be in
a trusted position and be able to reach key services on other hosts, which
may be further exploitable.
n You may be able to make network connections back out of the hosting
infrastructure to your own computer. This may enable you to bypass the
application, easily transmitting large amounts of sensitive data gathered
from the database, and often evading many intrusion detection systems.
n You may be able to extend the database’s existing functionality in arbitrary
ways by creating user-defined functions. In some situations, this may enable
you to circumvent hardening that has been performed on the database by
effectively reimplementing functionality that has been removed or disabled.
There is a method for doing this in each of the mainstream databases,
provided that you have gained database administrator (DBA) privileges.
COMMON MYTH
Many database administrators assume that it is unnecessary to defend the database
against attacks that require authentication to exploit. They may reason
that the database is accessed by only a trusted application that is owned by the
same organization. This ignores the possibility that a flaw within the application
may enable a malicious third party to interact with the database within the
application’s security context. Each of the possible attacks just described should
illustrate why databases need to be defended against authenticated attackers.