Application Security - Implementing Database Security and Auditing - page 171

you that this will simplify your environment and increase security. Do not
do this ! Even if you have that ability (i.e., it is a custom application and it
can be completely encapsulated within the database server), it is likely that
doing this will make the situation worse rather than better.
Running everything within the database will not take out application
flaws; the same flaws will now be running directly within the database, and
therefore the database is actually more exposed. In addition, you will now
have to worry about many things that are not within your realm of exper-
tise, such as cross-site scripting, cookie poisoning, session hijacking, and so
on. If you are running everything on one server, an attacker who finds a
vulnerability can “widen” the hole using either the database or the Web
server or any other component. As an example, an attacker can use a SQL
injection vulnerability to call an external procedure (see Chapter 7) to mod-
ify configuration files on the Web server or application server, thereby com-
pletely opening up the system to Web access. If you have good software
layering, you can use numerous security products and apply defense-in-
depth strategies; tools such as application firewalls, database firewalls, and
database intrusion detection systems can help secure your environment as
discussed. If everything runs within the database server, you are completely
on your own. In addition, running everything inside the database is not a
good use of the database resources, because that's what application servers
were meant to do.
A set of guidelines regarding what not to run within the database server
is the main topic of Chapter 7, and this section is not meant to replace that
discussion. I only want to warn against moving all application login into
the database in the context of the application vulnerabilities reviewed here
to make sure you don't make this mistake. Furthermore, you need to realize
that the more complex the database server is (in terms of the types of func-
tions it supports directly), the more bugs it will have, the more misconfigu-
rations it will have, and the more exploitable vulnerabilities it will have. As
an example, if the server can process Web services, more code runs as part of
the server. More code means more bugs, so having this “open and available”
means that there are more ways to attack your database.

5.6 Address packaged application suites

If you are like most people, you probably think about your homegrown
custom applications when you think of application vulnerabilities and how
they affect your database. The reason is twofold: (1) you tend to know more
about your own applications than about packaged suites, and (2) you may