Application Security
5.6 Address packaged application suites
Chapter 5
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
172 5.6 Address packaged application suites
think that application developers within your organization have bad habits.
This view is somewhat valid, but not completely so. Although packaged application suites have many more man-years of development and testing invested in them (usually making them better tested and more secure), these suites have many vulnerabilities of their own. In fact, application suites by companies such as SAP, Oracle, PeopleSoft, and Siebel are so broad and so functional that their sheer size means they are bound to have bugs. Many of these packages have millions of lines of code, often written in multiple programming languages by many generations of developers.
Furthermore, because these systems are used to run the enterprise, they are often tailored and customized beyond the core product—customizations that are usually deployed with short time tables and even less testing.
If you are working in a large enterprise, it is likely that you have one of these application suites installed, and because these systems are used for Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), and the like, these application suites often have a direct connection into the most important databases in your organization. As the owner of database security, you must therefore also understand what kind of vulnerabilities these applications may intro-duce into your environment and what you can do about them.
5.6.1 Anatomy of the vulnerability: All applications have bugs
If debugging is the process of removing bugs, then development is the pro-cess of inserting them. Big application suites have their own vulnerabilities, many falling into the same classes as the ones you’ve seen in this chapter. As an example, Oracle E-Business Suite versions 11.0.x and versions 11.5.1 through 11.5.8 have multiple SQL injection vulnerabilities that allow an attacker to inject SQL into nonvalidated input fields on Web forms.
Because of the design and level of trust between an Oracle database and the application, these attacks can compromise the entire database. A few rele-vant security alerts and the Oracle Applications versions they pertain to are shown in Table 5.1.
Let’s continue with the example of Oracle Applications and an Oracle database; this is not to say that other packaged suites have no equivalent vulnerabilities, because they do. What other issues will you encounter in addition to SQL injection? Well, practically every issue you’ve learned about until now. In Chapter 1 you learned that you should drop default users and schemas. Such vulnerabilities exist in Oracle Applications—there
5.6 Address packaged application suites 173
Chapter 5
are approximately 15 default accounts, default passwords, and default con-figuration settings that must be changed or dropped. By default there is no sign-on failure limit, so password cracking is a vulnerability. Another prob-lem that is common to most, if not all, application suites is a mismatch between the application user model and the database user model. Oracle Applications accesses the database using the APPS account; no information is passed to the database allowing it to enforce tighter controls on which data can be accessed and which operations performed. This issue is further discussed in the next section and in Chapter 6.
In Chapter 3 you learned that the database should also be viewed as a networked server and that you should address network security for your database. The same is true for packaged suites. In fact, these deployments tend to be far more complex. As an example, in a full deployment of Ora-cle Applications, you will normally have the ports shown in Table 5.2 to worry about.
Table 5.1 Oracle security alerts for Oracle Applications
Oracle Security Alert Number Vulnerable Oracle Applications Versions
32 11.5.1-11.5.6
44 11i
53 10.7-11.5.8
56 11.5.1-11.5.8
57 11.0.x, 11.5.1-11.5.8
Table 5.2 Oracle ports for Oracle Applications servers
Server Ports
Oracle Database Server 1521
Oracle Application Server 80, 443 and sometimes 2649, 8888 and 7777 Oracle Forms Listener 9000
Oracle WebDB Listener 2002
Oracle TCF Server 10021-10029, 15000 Oracle Report Review Agent 1526
Oracle Metric Server 9010, 9020
174 5.6 Address packaged application suites
5.6.2 Implementation options: Patch and monitor At the beginning of the chapter, I commented on the fact that application developers view the database as part of the application. In application suites this is even more so, and the database truly belongs to the application. In fact, as a DBA you may have few options in terms of securing this database.
You are certainly not free to change privileges and control definitions, because these may break the application. Your options are far more limited than in the case of homegrown applications. Not only can you not make any active changes, but you cannot even suggest better coding practices. All you are really left with is patch management and the use of third-party tools to monitor, audit, protect, and alert on potential problems. Luckily, many of the techniques discussed in Chapters 1 to 5 are applicable here.
Let’s start with patch management. The security alerts listed in Table 5.1 point to patches that you should apply if you are running Oracle Applica-tions. In all cases, you should monitor all such security alerts on sites such as www.cert.org, www.securiteam.com, and www.net-security.org. Next, remember that the database is not truly a part of the application (or rather, not only a part of the application). In any enterprise implementation, many interfaces are built to these databases, sometimes through specialized mid-dleware and sometimes by direct access to the database. These connections further increase the risk, but more important, they mean that you cannot completely rely on the security system built into the application suite and must address database security in tangent.
Most important, you should apply everything you’ve learned thus far (and everything you will learn in future chapters), because most techniques apply equally well to packaged application suites as they do to custom applications. Some examples include the following:
Monitor where queries are coming from and classify DML versus SELECTs based on source.
Monitor and define an access control policy that pertains to any access from interface programs and scripts.
Consider using a SQL firewall to provide an access control layer that compensates for your lack of ability to alter the schema and define the privileges to the database. If you decide against deploying such a firewall, limit access to the database from the network nodes that run the application servers and the interfaces.
5.8 Summary 175
Chapter 5
Create a baseline and alert on divergence. Application suites certainly fall within the realm for repeating queries, and using a baseline for intrusion detection is an effective way to combat SQL injection and other such attacks.
Finally, you should look into best practice techniques for securing the application suite of your choice and into using third-party products that can help you secure your application suite environments. As an example, AppSentry by Integrigy is a security scanner specifically built for Oracle Applications; it offers more than 300 audits and tests targeted for Oracle Applications.