| Oracle® Application Server Best Practices Guide 10g (10.1.4.0.1) Part Number B31762-02 |
|
|
View PDF |
| Oracle® Application Server Best Practices Guide 10g (10.1.4.0.1) Part Number B31762-02 |
|
|
View PDF |
This chapter describes security and management best practices for Oracle Application Server. It includes the following topics:
This section describes general best practices for security and management. It includes the following topics:
Section 4.1.2, "Assign Lowest-Level Privileges Adequate for the Task to Contain Security Leaks"
Section 4.1.10, "Place Application Server in the DMZ to Prevent Security Issues"
Section 4.1.11, "Use Secure Sockets Layer Encryption to Secure LDAP and HTTP Traffic"
Section 4.1.12, "Tune the SSLSessionCacheTimeout Directive to Meet Your Application Needs"
The following are recommended for using HTTPS with Oracle Application Server:
Configure Oracle Application Server to fail attempts that use weak encryption. You can configure Oracle Application Server to use only specific encryption ciphers for HTTPS connections. Connections from all old Web browsers that have not upgraded the client-side Secure Sockets Layer (SSL) library to 128-bit can be rejected. This functionality 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. Huge performance overhead of HTTPS forces a trade-off in some situations. Use of HTTPS to HTTP appliances can change throughput from 20 to 30 transactions for each second on a 500 MHz Unix to 6000 transactions for each second for a relatively low cost, making this trade-off decision easier. This solution is better than math and crypto cards, which can be added to UNIX, Windows, and Linux computers.
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 computer. 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 access, then the access is routed to the same Web server.
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 that require SSL. Put pages that do not require 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
When assigning privileges to modules, use the lowest levels adequate to perform the modules functions. This assignment is essentially fault containment, that is, if security is compromised, it is contained within a small area of the network and cannot invade the entire intranet.
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 configuration will avoid cluttering client Web browsers, which may cause errors if the Web browser cannot transmit all the valid cookies. Set non-permanent cookies to expire when the relevant application exits.
Make sure that information in cookies contains Method Authentication. Use authentication to ensure that cookie data has not been changed since the application set the data. This authentication helps ensure that the cookie cannot be modified and deceive 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 Web browsers support. If this is exceeded, then the Web 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.
Use the following as guidelines for system setup:
Apply all relevant security patches. Check MetaLink (http://metalink.oracle.com) and OTN (http://www.oracle.com/technology/index.html) for current security alerts. Many of these patches address publicly announced security issues.
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. 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 and rcp.
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. These errors may not have occurred when the original transaction was processed. For these cases, view the audit trail to simulated authentication at the time when the transaction was initially processed.
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 will not 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. You can use some utilities 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 through input from Web browsers (or processes that act like Web browsers) to invoke scripting engines inappropriately. However, it is not limited to the Web technologies, and you should evaluate all code for this.
The following are some common recommended practices pertaining to firewalls; while not unique to Oracle Application Server, these are important to overall Oracle Application Server 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 configuration blocks the types of intrusion that 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, such as IIOP, leave ports open without receiving processes. Port and IP combinations that 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. Bastion hosts are fortified servers on the perimeter network. Segment information and processing such that the bastion hosts 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 Oracle Application Server for better security. For example, HTTP, AJP, OCI, LDAP.
Oracle HTTP Server has several features that provide security to an application without requiring the application to be modified. Leverage or evaluate these features 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. 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.
Leverage these three features before designing any application-specific security mechanisms.
Oracle recommends 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.
Application servers should exist in the DMZ. In this architecture, OracleAS Web Cache only forwards requests to computers containing Web servers. Web servers only forward requests to application servers or through PL/SQL to database servers. The application servers only forward inward requests to the database or, perhaps, special message processing processors in the intranet. This configuration provides excellent fault containment because a compromised Web server must somehow compromise an application server before the database can be attacked.
You can use Secure Sockets Layer (SSL) encryption to secure both LDAP and HTTP traffic that passes between the various components of the Oracle Application Server. To ensure that all LDAP queries being sent to Oracle Internet Directory are SSL-encrypted, you need to configure your Oracle Internet Directory instance to run with a configuration set that supports only SSL-encrypted LDAP connections. The default mode installed with Oracle Application Server allows a given Oracle Internet Directory instance to be configured to listen on both SSL and non-SSL ports.
SSL encryption is unrelated to the installation or use of HTTPS, which allows users to access Oracle Application Server components over HTTP while using SSL to encrypt Web client packets.
See Also:
Oracle Internet Directory Administrator's Guide for more details on configuring Oracle Internet Directory instances with SSLThe Apache server in Oracle Application Server caches a client 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 five connections was approximately 11.4 seconds without SSL session caching as opposed to approximately 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.
Consult the Oracle Application Server Enterprise Deployment Guide and the Oracle Identity Management Infrastructure Administrator's Guide when planning out the final target topology. Identify the steps in installing and configuring the various Oracle Application Server components consistent with the options of the Oracle Universal Installer, rather than approaching the desired topology on an adhoc basis.
Oracle Application Server provides an implementation of OracleAS JAAS Provider for J2EE applications that is fully integrated with J2EE declarative security. This implementation allows J2EE applications to take advantage of the JAAS constructs, such as principal-based security and pluggable login modules. Optionally, the OracleAS JAAS Provider implementation allows J2EE applications running on OC4J to leverage the central security services of Oracle Identity Management.
This section describes Oracle Containers for J2EE (OC4J) security best practices. It includes the following topics:
The OC4J container continues to provide several methods and levels of extending security providers. You can extend the UserManager class to build a custom user manager that enables you to leverage the functionality provided by the OracleAS JAAS Provider. Both OracleAS Single Sign-On and Oracle Internet Directory provide APIs to integrate with external authentication servers and directories respectively, thus allowing developers more time to focus on actual business logic instead of infrastructure code.
OC4J allows different authentication options for J2EE applications. Oracle recommends leveraging the OracleAS Single Sign-On server whenever possible for the following reasons:
It is the default mechanism for most Oracle Application Server components such as OracleAS Portal, OracleAS Forms Services, OracleAS Reports Services, and OracleAS Wireless.
It is easy to setup in a declarative fashion and does not require any custom programming.
It provides a seamless way for PKI integration.
For environments where OracleAS Single Sign-On is not available, and custom authentication is required, one should use JAAS-compliant LoginModules to extend OC4J authentication. When using LoginModules, it is important to only use application relevant principals (roles) associated with the authenticated subject to preserve least privilege.
Unlike the coarse-grained J2EE authorization model as it exists today, the OracleAS 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.
For example, you can write a servlet with Subject.doAs or Subject.doPrivileged to control code that executes sensitive operations.
Although the OracleAS JAAS Provider supports a flat-file XML-based repository useful for development and testing environments, configure it 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. To optimize performance, adjust the caching configurations appropriate for your environment.
Simple J2EE applications using HTTP Basic authentication do not support the concept of logout, relying instead on the user to close the Web browser. When using other forms of authentication, including OracleAS Single Sign-On, it is important to plan out various logout and timeout flows. OC4J has an adjustable HTTP session inactivity parameter that is set to 20 minutes by default. If J2EE applications are leveraging OracleAS Single Sign-On and want to support full logout functionality, write them with the appropriate logout dynamic directives.
This section provides best practices for securing the OC4J environment. It contains the these topics:
The OC4J administration application is installed by default in every OC4J instance. Access to this application should be restricted to the local machine, that is, connections coming from 127.0.0.1 only, or to a set of trusted hosts. This is achieved by using OC4J's built in IP access controls.
Implementation Details
Open the orion-web.xml file located in the application-deployments directory, usually located at:
$ORACLE_HOME/j2ee/home/application-deployments/ascontrol/ascontrol/orion-web.xml
Add the following element to orion-web-app:
<access-mask default="deny">
<ip-access ip="127.0.0.1" mode="allow"/>
</access-mask>
OC4J's default configuration provides many features that enable ease of use and development. Many features are enabled by default, and the product is configured to provide informative error messages. This is not really a problem when OC4J is used in a development environment. However, this configuration may not meet your needs in a production environment.
Disabling debug mode will stop OC4J from echoing stack traces back to end user through HTTP. However, stack traces will still be available in log files to assist with debugging of applications.
Implementation Details
You can turn debug mode off by setting Java system properties when running OC4J, or in opmn.xml with:
java -DDebug=false -jar oc4j.jar
The Default Invoker is a legacy convention that allows a given servlet to be invoked directly by class name, rather than by a specific mapping in a configuration file. For example, assume there is a servlet named servlet com.foo.bar.FooBarServlet. This servlet is mapped to /FooBar by a configuration file and there is access control on it. Only authenticated users are allowed to invoke it because it performs some sensitive function. If OC4J has the Default Invoker functionality enabled, then this restriction can be bypassed as an attacker can invoke the servlet directly, for example, by requesting /servlet/com.foo.bar.FooBarServlet. As a result, you must remove this functionality.
Implementation Details
To implement this best practice:
Disable directory browsing to avoid exposing how an application works to malicious users.
Implementation Details
Ensure the <orion-web-app> element has the following attribute in the orion-web.xml file:
directory-browsing="deny"
This setting is the default setting.
Certain attacks against J2EE containers and Web servers rely on tricking the container into returning an unprocessed resource. Returning the source code to a .jsp rather than compiling and executing it server side is one example. To prevent such attacks, disable file aliases.
Implementation Details
Define the following Java startup parameter:
-Dhhtp.file.allowAlias=false
OC4J Standalone forces a password to be set at installation time for the OC4J administrator account, oc4jadmin. However, when you install other versions of OC4J, particularly those consumed by other parts of the Oracle product stack, well-known passwords are automatically set. Be sure to change all of your passwords to ones that cannot be easily guessed or broken.
By default, system-jazn-data.xml is used by OC4J. The oc4jadmin account is created in this file, but de-activated out of the box. You have to activate this account by providing a new password either during install time or during first time start-up of OC4J.
Use password indirection to avoid the presence of clear text passwords in any of the OC4J XML configuration files. With password indirection the stored password is obfuscated, and can be retrieved when needed from the OC4J security sub-system. This mechanism is only available when the security provider of your application is set to be the XML file-based or Oracle Identity Management providers.
Implementation Details
Add ->UserName in the XML configuration to represent the password.
Remote Method Invocation (RMI) by default listens on port 23791. You can restrict it with the following methods:
Add the host attribute to the rmi-server element in rmi.xml.
<rmi-server port="23791" host="127.0.0.1">
Use the access region set element
<access-mask default="deny">
<ip-access ip="127.0.0.1" mode="allow"/>
</access-mask>
The Java Messaging Service (JMS) listens by default on port 9127. You can restrict access to specific hosts by adding the host attribute to the jms-server element.
<jms-server port="9127" host="127.0.0.1">
This section describes Oracle Application Server Single Sign-On (OracleAS Single Sign-On) best practices. It features the following topics:
Section 4.4.1, "Configure for High Availability to Prevent Inaccessible Applications"
Section 4.4.2, "Leverage OracleAS Single Sign-On to Optimize Administration and Customer Experience"
Section 4.4.3, "Use an Enterprise-Wide Directory to Eliminate User Data in Multiple Systems"
Section 4.4.4, "Use OracleAS Single Sign-On to Validate User Credentials"
Section 4.4.5, "Always Use SSL with Oracle Application Server to Protect Applications"
Single sign-on failure is catastrophic, since it means no single sign-on protected application can be accessed. Two recommendations for high availability of OracleAS 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. Oracle also recommends that the database be a Oracle Real Application Cluster configured for additional improvements in availability.
See Also:
Oracle Application Server Single Sign-On Administrator's Guide
Whitepaper Expose your Intranet Portal to the Outside World in a Secured Manner available from the Oracle Technology Network at http://www.oracle.com/technology/index.html for configuring multiple single sign-on servers
Use OracleAS Single Sign-On as the primary point of security. This component provides benefits from an administrative point of view and is a major convenience to application customers. Also, OracleAS Single Sign-On is well integrated with the rest of Oracle Application Server Infrastructure and can, with 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.
Using an OracleAS Single Sign-On single-authenticated user for all applications provides better control for more uniform authorization.
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, such as in multiple Microsoft Windows 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.
OracleAS Single Sign-On provides the infrastructure to validate credentials and allows for various different authentication mechanisms, such as username, password, and X.509 certificates. Moreover, since these mechanisms 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.
The OracleAS Single Sign-On server simplifies user interaction by providing a mechanism to have a single username and password, which can be used by multiple partner applications. With this ease of use, 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 partner applications at risk. Therefore, always configure the single sign-on server to allow connections in SSL mode only. This configuration protects the end user's credentials going across the wire. Applications where security and data confidentiality are important should also be protected by SSL. From a performance perspective, use of SSL hardware accelerators is recommended.
The OracleAS Single Sign-On server provides a standard login screen. This login page is serviced from the single sign-on server, which typically is installed on a different computer from the one the end user is trying to access. Thus, it is critical that before the end user enters their login and password, that a valid single sign-on screen is observed. This screen prevents users from unknowingly providing their username or password to inappropriate servers.
Most users do not log out of Internet applications and this issue creates problems at two levels:
A security risk. Another person accessing the work station can now reuse the cookie. Also, since the session remains valid until it times out, a hacker from another computer has a longer time window to guess the session ID or 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, configure single sign-on session duration and inactivity timeouts appropriately. For example, configure one-hour inactivity timeouts for sensitive applications.
For external applications, OracleAS Single Sign-On cannot log out users. Therefore, closing all Web browser windows is important.
