|Oracle® Application Express Application Builder User's Guide
Part Number E21674-05
|PDF · Mobi · ePub|
This section describes security best practices for Oracle Application Express administrators.
The embedded PL/SQL gateway runs in the database as part of the XML DB HTTP Protocol Listener. The XML DB HTTP Protocol Listener and embedded PL/SQL gateway provides the equivalent core features of Oracle HTTP Server and
mod_plsql. Because the HTTP Listener runs in the same database where Oracle Application Express is installed, it is not possible to separate the HTTP listener from the database. For this reason, it is not recommended to use the embedded PL/SQL gateway for applications that run on the Internet. Additionally, the embedded PL/SQL gateway does not provide the same flexibility of configuration and detailed logging as Oracle HTTP Server with
Oracle HTTP Server uses the
mod_plsql plug-in to communicate with the Oracle Application Express engine within the Oracle database.
mod_plsql functions act as a communication broker between the Web server and the Oracle Application Express engine in the Oracle database.
mod_plsql request is associated with a set of configuration values used to access the database called a Database Access Descriptor (DAD).
mod_plsql provides a DAD parameter called
PlsqlRequestValidationFunction which enables you to allow or disallow further processing of a requested procedure. You can utilize this parameter to implement tighter security for your PL/SQL application by blocking package and procedure calls which should not be allowed to run from the DAD. Oracle recommends a DAD configuration for Oracle Application Express which utilizes the
PlsqlRequestValidationFunction directive with a value of
The purpose of the
PlsqlRequestValidationFunction parameter is to control which procedures can be invoked through
mod_plsql. By default, the only procedures permitted are the public entry points of Oracle Application Express. This can be extended using the validation functions shipped with Oracle Application Express. To learn more, see "Restricting Access to Oracle Application Express by Database Access Descriptor (DAD)" in Oracle Application Express Administration Guide.
Secure Sockets Layer (SSL) is a protocol for managing the security of data transmitted on the Internet. For Web applications, SSL is implemented by using the HTTPS protocol. Oracle recommends that you run Oracle Application Express applications using SSL (HTTPS protocol) to prevent any sensitive data from being sent over an unencrypted (cleartext) communication channel.
You can configure both your Oracle Application Express instance and all related applications to require HTTPS by setting the Require HTTPS attribute to Yes on the Security Settings page in Oracle Application Express Administration Services.
Setting the Require HTTPS attribute to Yes and logging out prevents anyone from logging in to Oracle Application Express Administration Services and from logging into an Oracle Application Express workspace as a developer or administrator unless the protocol in use is HTTPS.
See Also:"Requiring HTTPS" in Oracle Application Express Administration Guide
Oracle recommends that you employ Secure Sockets Layer (SSL) when integrating Oracle Application Express with Oracle BI Publisher. Once SSL (HTTPS protocol) is configured for your Oracle BI Publisher server, you must create a wallet and specify the HTTPS protocol for the Report Server in the internal administration Environment Settings.
Workspace administrators and developers can create user accounts for the purpose of logging in to the Oracle Application Express development environment and for end-user authentication to applications developed within their workspaces. The Oracle Application Express administrator can create password complexity rules, or a policy, for the passwords of these accounts. These rules apply to all accounts in the installation, across all workspaces.
The following are example password complexity policies:
All passwords must:
Contain at least one upper-case character
Contain at least one numeric digit
Must be at least six characters long
Note that many other variations are possible. Oracle recommends administrators establish a password complexity policy for each Oracle Application Express instance. To learn more, see "Enabling Login Controls for All Workspaces," "About Strong Password Policies," and "Enabling Account Login Controls for a Workspace" in Oracle Application Express Administration Guide.
Site administrators can restrict password reuse for all administrator, developer, and end-user accounts based on a history of passwords previously used for the accounts.
To restrict password reuse:
Start SQL*Plus and connect to the database where Oracle Application Express is installed having the
apex_administrator_role role or as
SYS specifying the
SYSDBA role. For example:
SYSTEM_DRIVE:\ sqlplus /nolog SQL> CONNECT SYS as SYSDBA Enter password: SYS_password
On UNIX and Linux:
$ sqlplus /nolog SQL> CONNECT SYS as SYSDBA Enter password: SYS_password
APEX_ADMINISTRATOR_ROLEmust be granted directly to a user and not through another database role.
Execute the following statement:
ALTER SESSION SET CURRENT_SCHEMA = APEX_040100;
Execute the following statement:
BEGIN APEX_INSTANCE_ADMIN.SET_PARAMETER('PASSWORD_HISTORY_DAYS',365); COMMIT; END; /
This will restrict new or updated passwords to those that have not been used for the account for the previous 365 days. Recording of previously used passwords (actually, hashed representations of passwords) begins upon installation of Oracle Application Express.
To disable this feature, run the block above, providing 0 for the parameter value. For example:
BEGIN APEX_INSTANCE_ADMIN.SET_PARAMETER('PASSWORD_HISTORY_DAYS',0); COMMIT; END; /
Tip:Developers can also use the
APEX_UTIL.STRONG_PASSWORD_CHECKprocedure and the
APEX_UTIL.STRONG_PASSWORD_VALIDATIONfunction described in Oracle Application Express API Reference.
An Oracle Application Express runtime environment enables you to run production applications, but it does not provide a Web interface for administration or direct development of these applications
Oracle recommends that you run any sensitive production Oracle Application Express applications with a runtime installation of Oracle Application Express. A runtime installation does not expose the Web-based application development environment, thus preventing the use of Application Builder, SQL Workshop, and related utilities on a production installation. Additionally, a runtime environment only includes the Oracle Application Express database objects and privileges necessary to run applications, making it a more hardened environment.
See Also:"Managing a Runtime Environment" in Oracle Application Express Administration Guide
By configuring Session Timeout attributes, you can reduce your application's exposure. Users often leave their computers unattended for extended periods and do not close applications before departing. Therefore, an unauthorized person can easily assume the user's identity within the application. By setting the session and idle timeout, users are automatically logged out of their application after the specified timeout.
Session Timeout attributes include:
Maximum Session Length in Seconds
Session Timeout URL
Maximum Session Idle Time in Seconds
Idle Timeout URL
To learn more about configuring these attributes at an application-level, see "Session Timeout". To learn more about configuring these attributes for an entire Oracle Application Express instance, see "Configuring Session Timeout" in Oracle Application Express Administration Guide.
By default, the ability to interact with network services is disabled in Oracle Database 11g. Therefore, if you are running Oracle Application Express with Oracle Database 11g, you must use the new
DBMS_NETWORK_ACL_ADMIN package to grant connect privileges to any host for the
APEX_040100 database user. Failing to grant these privileges results in issues with:
Sending outbound mail in Oracle Application Express.
Users can call methods from the
APEX_MAIL package, but issues arise when sending outbound email.
Using Web services in Oracle Application Express.
Tip:To run the examples described in this section, the compatible initialization parameter of the database must be set to at least Oracle Database 18.104.22.168.0. By default an 11g database will have the parameter set properly, but a database upgraded to 11g from a prior version may not. See "Creating and Configuring an Oracle Database" in Oracle Database Administrator's Guide for information about changing database initialization parameters.
The following example demonstrates how to grant connect privileges to a host for the
APEX_040100 database user.
DECLARE ACL_PATH VARCHAR2(4000); BEGIN -- Look for the ACL currently assigned to '*' and give APEX_040100 -- the "connect" privilege if APEX_040100 does not have the privilege yet. SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL; IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'APEX_040100', 'connect') IS NULL THEN DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH, 'APEX_040100', TRUE, 'connect'); END IF; EXCEPTION -- When no ACL has been assigned to '*'. WHEN NO_DATA_FOUND THEN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('power_users.xml', 'ACL that lets power users to connect to everywhere', 'APEX_040100', TRUE, 'connect'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*'); END; / COMMIT;
The following example is a less privileged demonstration of how to access resources on a local host. This example could possibly enable email and PDF printing if those servers were also on the local host.
DECLARE ACL_PATH VARCHAR2(4000); BEGIN -- Look for the ACL currently assigned to 'localhost' and give APEX_040100 -- the "connect" privilege if APEX_040100 does not have the privilege yet. SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS WHERE HOST = 'localhost' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL; IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'APEX_040100', 'connect') IS NULL THEN DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH, 'APEX_040100', TRUE, 'connect'); END IF; EXCEPTION -- When no ACL has been assigned to 'localhost'. WHEN NO_DATA_FOUND THEN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('local-access-users.xml', 'ACL that lets users to connect to localhost', 'APEX_040100', TRUE, 'connect'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('local-access-users.xml','localhost'); END; / COMMIT;
If you receive an
ORA-44416: Invalid ACL error after running the previous script, use the following query to identify the invalid ACL:
REM Show the dangling references to dropped users in the ACL that is assigned REM to '*'. SELECT ACL, PRINCIPAL FROM DBA_NETWORK_ACLS NACL, XDS_ACE ACE WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL AND NACL.ACLID = ACE.ACLID AND NOT EXISTS (SELECT NULL FROM ALL_USERS WHERE USERNAME = PRINCIPAL);
Next, run the following code to fix the ACL:
DECLARE ACL_ID RAW(16); CNT NUMBER; BEGIN -- Look for the object ID of the ACL currently assigned to '*' SELECT ACLID INTO ACL_ID FROM DBA_NETWORK_ACLS WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL; -- If just some users referenced in the ACL are invalid, remove just those -- users in the ACL. Otherwise, drop the ACL completely. SELECT COUNT(PRINCIPAL) INTO CNT FROM XDS_ACE WHERE ACLID = ACL_ID AND EXISTS (SELECT NULL FROM ALL_USERS WHERE USERNAME = PRINCIPAL); IF (CNT > 0) THEN FOR R IN (SELECT PRINCIPAL FROM XDS_ACE WHERE ACLID = ACL_ID AND NOT EXISTS (SELECT NULL FROM ALL_USERS WHERE USERNAME = PRINCIPAL)) LOOP UPDATE XDB.XDB$ACL SET OBJECT_VALUE = DELETEXML(OBJECT_VALUE, '/ACL/ACE[PRINCIPAL="'||R.PRINCIPAL||'"]') WHERE OBJECT_ID = ACL_ID; END LOOP; ELSE DELETE FROM XDB.XDB$ACL WHERE OBJECT_ID = ACL_ID; END IF; END; / REM commit the changes. COMMIT;
Once the ACL has been fixed, you must run the first script in this section to apply the ACL to the
APEX_040100 user. See "Granting Connect Privileges to a Host".