9
Security Best Practices

This chapter describes security best practices. The topics include:

9.1 General Best Practices

This section describes general best practices. The topics include:

9.1.1 Best Practices for HTTPS Use

The following are recommended for using HTTPS with Oracle9iAS:

Configure Oracle9iAS to fail attempts to use weak encryption. Oracle9iAS can be configured to use only specific encryption ciphers for HTTPS connections. Thus, connections from all old browsers that have not upgraded the client-side SSL libraries to 128-bit can be rejected. This ability is especially useful for banks and other financial institutions because it provides server-side control of the encryption strength for each connection.
Use HTTPS to HTTP appliances for accelerating HTTP over SSL. You should in general use HTTPS everywhere you need to. However, the huge performance overhead of HTTPS forces a trade-off in some situations. Use of HTTPS to HTTP appliances can change throughput from 20/30 transactions per second on a 500MHz Unix to 6000 transactions per second for a relatively low cost, making this trade-off decision easier. Moreover, these are much better solutions than the math/crypto cards, which can be added to UNIX/NT/Linux boxes.
Ensure that sequential HTTPS transfers are requested through the same Web server. Expect 40/50 milliseconds CPU time for initiating SSL sessions on a 500 MHz machine. Most of this CPU time is spent in the key exchange logic, where the bulk encryption key is exchanged. Caching the bulk encryption key will significantly reduce CPU overhead on subsequent accesses, provided that the accesses are routed to the same Web server. This improves performance.
Keep secure pages and pages not requiring security on separate servers. While it may be easier to place all pages for an application on one HTTPS server, the resulting performance cost is very high. Reserve your HTTPS server for pages needing SSL, and put the pages not needing SSL on an HTTP server.

If secure pages are composed of many GIF, JPEG, or other files that would be displayed on the same screen, it is probably not worth the effort to segregate secure from non-secure static content. The SSL key exchange (a major consumer of CPU cycles) is likely to be called exactly once in any case, and the overhead of bulk encryption is not that high.

9.1.2 Assign Lowest Level Privileges Adequate for the Task

When assigning privileges to module(s), use the lowest levels adequate to perform the module(s) function(s). This is essentially "fault containment" which means if security is compromised, it is contained within a small area of the network and cannot invade the entire intranet.

9.1.3 Best Practices for Cookie Security

Use the following as guidelines for cookies:

Make sure that cookies have proper expiration dates. Permanent cookies should have relatively short expiration dates of about three months or less. This will avoid cluttering client browsers, which may cause errors if the browser cannot transmit all the valid cookies. Non-permanent cookies should be set to expire when the relevant application exits.
Make sure that information in cookies should be "MAC'ed". Method Authentication should be used to ensure that cookie data has not been changed since the application set the data. This helps ensure that the cookie cannot be modified and "trick" the application. Also, this helps prevent application failures if the cookie is inadvertently corrupted.
Make sure that the size and varieties of cookies are kept low. There is a finite number and aggregate size of cookies that browsers support. If this is exceeded, then the browsers will not send all the relevant cookies leading to application failures. Also, very large cookies can result in performance degradation.
Carefully use cookie domain name facilities. Use of cookie domains should ensure that the domain is the smallest possible. Making the domain oracle.com, for instance, would mean that ANY host in oracle.com would get the cookie. With hundreds of applications on different parts of oracle.com, a domain of oracle.com for each of them results in attempts to send hundreds of cookies for each HTTP input operation.

9.1.4 Best Practices in Systems Setup

Use the following as guidelines for system setup:

Apply all relevant security patches. Check Metalink and TechNet for current security alerts. Many of these patches address publicly announced security holes.
When deploying software, change all default passwords and close accounts used for samples and examples.
Remove unused services from all hosts. Examples of unused services are FTP, SNMP, NFS, BOOTP, and NEWS. It is almost always worthwhile finding ways to eliminate FTP because it is especially noxious. HTTP or WebDAV may be good alternatives.
Limit the number of people with root and administrative privileges.
In UNIX, disable the `r' commands if you do not need them. For example, rhost, rcp.

9.1.5 Best Practices for Certificates Use

Use the following guidelines when using certificates:

Ensure that certificate organization unit plus issuer fields uniquely identify the organization across the Internet. One way to accomplish this would be to include the Dun and Bradstreet or IRS identification as identification for the issuer and the organizational unit within the certificate.
Ensure that certificate issuer plus distinguished name uniquely identify the user. If the combination of issuer and distinguished name is used as identification, there is no duplication risk.
Include expiring certificates in tests of applications using certificates. Expiration is an important consideration for a number of reasons. Unlike most username/password-based systems, certificates expire automatically. With longer duration certificates, fewer re-issues are required, but revocation lists become larger.

In systems where certificates replace traditional usernames/passwords, expiring certificate situations may result in unexpected bugs. Careful consideration of the effects of expiration is required and new policies will have to be developed because most application and infrastructure developers have not worked in systems where authorization might change during transactions.
Use certificate re-issues to update certificate information. Because certificates expire, infrastructure for updating expired certificates will be required. Take advantage of the re-issue to update organizational unit or other fields. In cases of mergers, acquisitions, or status changes of individual certificate holders, consider re-issuing even when the certificate has not yet expired. But pay attention to key management. If the certificate for a particular person is updated before it expires, for example, put the old certificate on the revocation list.
Audit certificate revocations. Revocation audit trails can help you reconstruct the past when necessary. An important example is replay of a transaction to ensure the same results on the replay as during the original processing. If the certificate of a transaction participant was revoked between the original and the replay, failures may occur which would not have occurred when the original transaction was processed. For these cases, the audit trail should be viewed to simulated authentication at the time when the transaction was initially processed.

9.1.6 Review Code and Content Against Already Known Attacks

It is quite common for viruses or known attacks to resurface in slightly altered shape or form. Thus, just because a threat has been apparently eliminated does not mean it won't resurface. Use the following as guidelines to minimize the recurrence of the threat:

Ensure that programs are reviewed against double encoding attacks. There area many cases where special characters, such as <, >, | are encoded to prevent cross-site scripting attacks or for other reasons. For example, '<' might be substituted for '>'. In a double encoding, the attacker might encode the '&' so that later decoding might involve the inadvertent processing of a >, <, or | character as part of a script. Prevention of this attack, unfortunately, can only be provided by careful program review, although some utilities can be used to filter escape characters that might result in double encoding problems in later processing.
Ensure that programs are reviewed against buffer overflow for received data.
Ensure that programs are reviewed against cross-site scripting attacks. This attack typically tricks HTML and XML processing via input from browsers (or processes which act like browsers) to invoke scripting engines inappropriately. However, it is not limited to the Web technologies, and all code should be evaluated for this.

9.1.7 Follow "Common Sense" Firewall Practices

The following are some common recommended practices pertaining to firewalls.

While not unique to Oracle9iAS, these are important to overall Oracle9iAS security.

Place servers providing Internet services behind an exterior firewall of the stateful inspection type. Stateful inspection means that the firewall keeps track of various sessions by protocol and ensures that illegal protocol transitions are disallowed through the firewall. This blocks the types of intrusion, which exploit illegal protocol transitions.
Set exterior firewall rules to allow Internet-initiated traffic only through specific IP and PORT addresses where SMTP, POP3, IMAP, or HTTP services are running. Some protocols (e.g. IIOP) leave ports open with no receiving processes. PORT and IP combinations, which are not assigned to running programs, should not be permitted.
Set interior firewall rules to allow messages through to the intranet only if they originate from servers residing on the perimeter network. All incoming messages must first be processed in the perimeter network.
Send outgoing messages through proxies on the perimeter network.
Do not store the information of record on bastion hosts. Information and processing should be segmented such that bastion hosts (fortified servers on the perimeter network) provide initial protocol server processing and generally do not contain information of a sensitive nature. The database of record and all sensitive processing should reside on the intranet.
Disallow all traffic types unless specifically allowed. allow only the traffic required by Oracle9iAS(e.g. HTTP, AJP, OCI, LDAP) for better security.

9.1.8 Leverage Declarative Security

Oracle HTTP Server has several features that provide security to an application without requiring the application to be modified. These should be leveraged and/or evaluated before programming similar functionality as those features into the application. Specifically:

Authentication - Oracle HTTP Server can authenticate users and pass the authenticated user-id to an application in a standard manner. (REMOTE_USER). It also supports single sign-on, thus reusing existing login mechanisms.
Authorization - Oracle HTTP Server has directives that can allow access to your application only if the end user is authenticated and authorized. Again, no code change is required.
Encryption - Oracle HTTP Server can provide transparent SSL communication to end customers without any code change on the application.

These three features should be leveraged heavily before designing any application specific security mechanisms.

9.1.9 Use the Oracle Integrated Version of JAAS

Oracle9iAS provides a J2EE compliant version of JAAS. One can use the infrastructure provided by Sun for configuring and managing users, roles and privileges or one can use JAAS integrated with Oracle9iAS Single Sign-On and Oracle Internet Directory infrastructure. The latter is better integrated with the rest of the Oracle infrastructure and results in less programming, better manageability, and more control than the standard offering. In addition, use of the Oracle infrastructure can greatly improve the scalability, failover, and management by substituting Oracle Internet Directory and other Oracle infrastructure for the text file administration of the standard offering.

9.1.10 Use Switched Connections in DMZ

It is recommended that all DMZ attached devices be connected by switched, not bussed connections. Furthermore, devices such as the Cisco 11000 series devices, which can provide IP, port, and protocol rules between each pair of connected devices are preferred.

9.1.11 Place Application Server in the DMZ

Application servers should be in the DMZ. In this architecture Oracle9iAS Web Cache only forwards requests to boxes containing Web servers; Web servers only forward requests to application servers (or via PL/SQL to database servers); application servers only forward inward requests to the database or, perhaps, special message processing processors in the intranet. This provides excellent fault containment because, except for PL/SQL which has special security, a compromised Web server must somehow compromise an application server before the database can be attacked - a very difficult and improbable situation.

9.1.12 Tune the SSL SessionCacheTimeout Directive if You Are Using SSL

The Apache server in Oracle9iAS caches a client's SSL session information by default. With session caching, only the first connection to the server incurs high latency.

In a simple test to connect and disconnect to an SSL-enabled server, the elapsed time for 5 connections was 11.4 seconds without SSL session caching as opposed to 1.9 seconds when session caching was enabled.

The default SSLSessionCacheTimeout is 300 seconds. Note that the duration of a SSL session is unrelated to the use of HTTP persistent connections. You can change the SSLSessionCacheTimeout directive in httpd.conf file to meet your application needs.

9.2 OC4J Security Best Practices

This section describes OC4J security best practices. The topics include:

9.2.1 Use the Oracle9iAS JAAS Provider for OC4J User Management in Place of principals.xml

In the earlier releases of Oracle9iAS, the J2EE application server component stored all user information in a file called principals.xml (including storing passwords in cleartext). The Oracle9iAS JAAS Provider provides a similar simple security model as a default without storing passwords in cleartext. However, it also provides tight integration with Oracle9iAS Infrastructure (including Oracle9iAS Single Sign-On and Oracle Internet Directory) out of the box. Hence, we strongly recommend that you leverage the Oracle9iAS JAAS Provider for J2EE security in OC4J.

9.2.2 Avoid Writing Custom User Managers and Instead Extend the JAAS Provider, Oracle9iAS Single Sign-On, and Oracle Internet Directory

The OC4J container continues to provide several methods and levels of extending security providers. Although the UserManager class can be extended to build a custom user manager, leveraging the rich functionality provided by the JAAS Provider, Oracle9iAS Single Sign-On, and Oracle Internet Directory will allow developers more time to focus on actual business logic instead of infrastructure code. Both Oracle9iAS Single Sign-On and Oracle Internet Directory provide APIs to integrate with external authentication servers and directories respectively.

9.2.3 Use Oracle9iAS Single Sign-On as the Authentication Mechanism with the JAAS Provider

Oracle9iAS JAAS Provider allows different authentication options. However, Oracle strongly recommends leveraging the Oracle9iAS Single Sign-On server whenever possible for the following reasons:

It is the default mechanism for most Oracle9iAS components such as Portal, Forms, Reports, Wireless etc.
It is easy to setup in a declarative fashion and does not require any custom programming.
It provides a seamless way for PKI integration.

9.2.4 Use the JAAS Provider's Declarative Features to Reduce Programming

Since most of the features in the Oracle9iAS JAAS Provider are controlled declaratively, particularly in the area of authentication, their setup can be postponed until deployment time. This not only reduces the programming tasks for integrating a JAAS based application, it also enables the deployer to control the same J2EE application via his/her environment-specific security models.

9.2.5 Use Fine-Grained Access Control Provided by the JAAS Provider and the Java Permission Model

Unlike the "coarse-grained" J2EE authorization model as it exists today, the JAAS Provider integrated with OC4J allows any protected resource to be modeled using Java permissions. The Java permission model (and associated Permission class) is extensible and allows a flexible way to define fine-grained access control.

9.2.6 Use Oracle Internet Directory as the Central Repository for the JAAS Provider in Production Environments

Although the JAAS Provider supports a flat-file XML-based repository useful for development and testing environments, it should be configured to use Oracle Internet Directory for production environments. Oracle Internet Directory provides LDAP standard features for modeling administrative metadata and is built on the Oracle database platform inheriting all of the database properties of scalability, reliability, manageability, and performance.

9.2.7 Take Advantage of the Authorization Features of the JAAS Provider

In addition to the authorization functionality defined in the JAAS 1.0 specification, the Oracle9iAS JAAS Provider supports:

hierarchical, role-based access control (RBAC)
the ability to partition security policy by subscriber (i.e. each user community).

Both of these extensions allow a more scalable and manageable framework for security policies covering a large user population.

9.3 Oracle9iAS Single Sign-On Best Practices

This section describes Oracle9iAS Single Sign-On best practices. The topics include:

9.3.1 Oracle9iAS Single Sign-On Servers Should Be Configured for High Availability

Single sign-on failure is catastrophic since it means no single sign-on protected application can be accessed. Two recommendations for high availability of Oracle9iAS Single Sign-On are:

Carefully consider inclusion of any other types of processing on the single sign-on servers since this can make instability more likely.
Consider deploying multiple single sign-on servers fronted by load balancing hardware to protect against failures in single sign-on listeners. In this case, the address of the load balancer is used as the single sign-on address and the single sign-on listener configuration information is replicated. It is also recommended that the database be Real Application Cluster (RAC) configured for additional improvements in availability. Configuration details for multiple single sign-on servers can be found in the Oracle Technology Network.

9.3.2 Leverage Oracle9iAS Single Sign-On Whenever Possible

Oracle9iAS Single Sign-On should be used as the primary point of security. This is a benefit administratively and a major convenience to application customers. Also, Oracle9iAS Single Sign-On is well integrated with the rest of Oracle infrastructure and can, via Oracle Internet Directory and other means, be integrated with non-Oracle application and infrastructure. Also, as single sign-on becomes a single point for authentication, opportunities to attack the multiple authentication entities of sites today are reduced. Finally, single sign-on's single authenticated user for all applications allows better control for more uniform authorization.

9.3.3 Have an Enterprise-Wide Directory in Place

In order to deploy an effective single sign-on solution, the user population must be centralized in a directory, preferably an LDAP-based directory such as Oracle Internet Directory. Having users represented in multiple systems (e.g. in multiple Windows NT domains) makes setting up the infrastructure for a common identity more difficult. In addition, clearly defining and automating the user provisioning process makes managing the single sign-on environment much easier.

9.3.4 Always Use Oracle9iAS Single Sign-On Instead of Writing Custom Authentication Logic

Oracle9iAS Single Sign-On provides the infrastructure to validate credentials and allows for various different authentication mechanisms such as username/password, X.509 certificates. Moreover, since these can be shared across different applications and web sites, end users do not have to create a new username/password for each different corporate application.

9.3.5 For Devloping Single Sign-on Enabled Applications, Use mod_osso and Not the Single Sign-on SDK

Oracle9iAS Single Sign-On provides an SDK, which can be leveraged to develop a partner application. This SDK was commonly used in earlier releases of Oracle9iAS. However, beginning in Release 2, all of the common usage patterns have been embodied in a new Oracle HTTP Server module, mod_osso, that requires significantly less programming than the SDK. By single sign-on enabling an application with mod_osso, the application will automatically get future enhancements without changing any code.

9.3.6 Always Use SSL with Oracle9iAS

The Oracle9iAS Single Sign-On server simplifies user interaction by providing a mechanism to have a single username and password that can be used by multiple partner applications. However, with this ease, comes the caution that the single sign-on server should always be accessed in the correct fashion; a breach of the common password can now put all the partner applications at risk. Hence, the single sign-on server should always be configured to allow connections in SSL mode only. This protects the end user's credentials going across the wire. Applications where security and data confidentiality is important should also be protected by SSL. From a performance perspective, use of SSL hardware accelerators is recommended.

9.3.7 Train Users to be Wary of Providing Their Oracle9iAS Single Sign-On Username and Password Anywhere Other Than Through the Oracle9iAS Single Sign-On URL

The Oracle9iAS Single Sign-On server provides a standard login screen. This login page is serviced from the single sign-on server machine, which is typically a different machine from the one the end user is trying to access. Thus, it is critical that before the end user enters her login and password, she ensures that she is at a valid single sign-on screen that looks the same as it always has - from a valid login server computer. This prevents users from unknowingly providing their username/password to inappropriate servers.

9.3.8 Train Users to Log Out So the Cookie Does Not Remain Active

This is generic and not really single sign-on specific, but it is of particular importance when leveraging single sign-on. Most users do not log out of Internet applications and this creates problems at two levels:

A security risk - since someone else walking to the station can now reuse the cookie. Also, since the session remains valid until it times out, a hacker from another machine has a longer time window to guess the session id/cookie value.
The system resources on the server associated with the cookie are not released until the session is ended or invalidated.

For application developers and administrators, single sign-on session duration and inactivity timeouts should be configured appropriately (for example, one hour inactivity timeouts for sensitive applications).

For external apps, single sign-on cannot logout users from external apps - so closing all browser windows is important in this case.

9 Security Best Practices