Tip:
This section references many settings in the Administration Services application. Functionality in the Administration Services application is not available in Oracle Database Cloud Service (Database Schema).This section describes security best practices for Oracle Application Express administrators.
About Configuring Oracle REST Data Services with Oracle Application Express
About Configuring Oracle HTTP Server with mod_plsql with Oracle Application Express
About Security Considerations When Using the Embedded PL/SQL Gateway
About the Advantages of the Application Express Runtime Environment
To access the Oracle Application Express development environment, users log in to a shared work area called a workspace. Oracle Application Express includes two different types of administrators:
Workspace administrators are users who perform administrator tasks specific to a workspace such as managing user accounts, monitoring workspace activity, and viewing log files.
Instance administrators are superusers that manage an entire hosted instance using the Application Express Administration Services application.
Tip:
The role of Instance administrator is not available in Oracle Database Cloud Service (Database Schema).See Also:
Oracle Application Express Administration Guide for more information workspace and instance administrationOracle REST Data Services (formerly known as Oracle Oracle Application Express Listener) is a J2EE application which communicates with the Oracle Database by mapping browser requests to the Application Express engine database over a SQL*Net connection. Oracle REST Data Services is the strategic direction for Oracle Application Express and Oracle recommends using it in practically all circumstances. In a production environment, you deploy Oracle REST Data Services web archive files to a supported Java EE application server, like Oracle Web Logic Server. Each deployment can be configured individually and serves the same purpose as a mod_plsql Database Access Descriptor, which is to communicate with an Oracle database.
An Oracle REST Data Services deployment configuration contains several security related parameters. In a configuration for Oracle Application Express, Oracle recommends to set the parameter security.requestValidationFunction to wwv_flow_epg_include_modules.authorize. This activates the white list of callable procedures which ships with Oracle Application Express and prohibits calls to other procedures. 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.
Tip:
mod_plsql is deprecated as of Oracle HTTP Server 12c (12.1.3). For more information about this deprecation, please see My Oracle Support Note 1576588.1. Oracle recommends using Oracle REST Data Services instead.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.
Each 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 wwv_flow_epg_include_modules.authorize.
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.
The embedded PL/SQL gateway runs in the database as part of the Oracle XML DB HTTP listener. The Oracle XML DB HTTP 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, Oracle does not recommend the embedded PL/SQL gateway for applications that run on the Internet or for production applications. Oracle recommends using Oracle REST Data Services instead. Additionally, the embedded PL/SQL gateway does not provide the same flexibility of configuration and detailed logging as Oracle REST Data Services.
This section provides a summary of security best practices when managing an Oracle Application Express instance.
See Also:
"Configuring Security Settings" in Oracle Application Express Administration GuideWorkspace 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.
Administrators can configure login controls for an entire instance or for each individual workspace. For example, if an Instance administrator configures account login controls in Oracle Application Express Administration Services that configuration applies to all Application Express accounts in all workspaces across an entire development instance.
If the Instance administrator does not enable login controls across an entire instance, then each Workspace administrator can enable the following controls on a workspace-by-workspace basis:
End-user account expiration and locking.
A maximum number of failed login attempts for end-user accounts.
The password lifetime (or number of days an end-user account password can be used before it expires for end-user accounts).
See Also:
"Creating Login Controls for an Instance" and "Creating Account Login Controls for a Workspace" in Oracle Application Express Administration Guide.The Allow Public File Upload attribute enables administrators to control whether unauthenticated users can upload files in applications that provide file upload capability.
See Also:
"Controlling Public File Upload" in Oracle Application Express Administration GuideAdministrators can restrict user access to an Oracle Application Express instance by entering a comma-delimited list of allowable IP addresses in the Restrict Access by IP Address attribute on the Manage Instance, Security page.
See Also:
"Restricting User Access by IP Address" in Oracle Application Express Administration GuideAdministrators can use the Instance Proxy attribute to configure an entire Oracle Application Express instance to use a proxy for all outbound HTTP traffic. Setting a proxy at the instance-level supersedes any proxies defined at the application-level or in web service references. If a proxy is specified, regions of type URL, Web services, and report printing will use the proxy.
See Also:
"Configuring a Proxy Server for an Instance" in Oracle Application Express Administration GuideSecure 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.
Instance administrators can configure both their Oracle Application Express instance and all related applications to require HTTPS by configuring the Require HTTPS and Require Outbound HTTPS attributes. Configuring these attributes forces authenticated pages within the Application Builder to require HTTPS which encrypts network communications. Changing the Require HTTPS option does not affect the web server in any way. You will still need to enable the web server for HTTPS for these options to have any meaning. To learn more about enabling HTTPS, see the documentation for your specific web server.
Require HTTPS options include:
Always - Enforces HTTPS for all applications (including the Oracle Application Express development and administration applications) to require HTTPS.
Development and Administration - Forces all internal applications within Oracle Application Express (that is, Application Builder, SQL Workshop, Instance Administration and so on) to require HTTPS.
Application specific - Makes HTTPS dependent on application-level settings.
See Also:
"Requiring HTTPS" in Oracle Application Express Administration GuideAdministrators can use the Allow RESTful Access attribute to control whether developers can expose report regions as RESTful services.
See Also:
"Controlling RESTful Services for an Instance" in Oracle Application Express Administration GuideThe Rejoin Sessions attribute controls if Oracle Application Express supports application URLs that do not contain session IDs. When rejoin sessions is enabled, Oracle Application Express attempts to use the session cookie to join an existing session, when a URL does not contain a session ID.
To use Rejoin Sessions, administrators must enable Rejoin Sessions at the application or page-level. Note that a more restrictive value of Rejoin Sessions at the instance-level overrides application and page settings.
While supporting session joins is convenient, it does present some serious security risks:
Triggering malicious session state changes or other modifications.
If an attacker tricks the user into clicking an application link, this can trigger malicious session state changes or other modifications. Because of this risk, Application Express requires a checksum that the attacker will not be able to guess when processing requests that alters data.
Triggering unintended changes between applications.
If a user has two applications open in separate tabs on the same Oracle Application Express instance, one application could trigger unintended changes in the other one. The attacking application could be written by a hacker or it could have an XSS vulnerability that enables an attacker to inject code. This application could use Ajax calls that simulate user interactions with the other application.
Tip:
For security reasons, Oracles recommends that administrators disable Rejoin Sessions unless they implement workspace isolation by configuring the Allow Hostname attribute at the workspace or instance-level. See "About Isolating Workspaces."Isolating workspaces is an effective approach to preventing browser attacks. The only way to truly isolate a workspace is to enforce different domains in the URL by configuring the Allow Hostnames attribute in Oracle Application Express Administration Services. When the URLs of the attacker and the victim have different domains and hostnames, the browser's same-origin policy prevents attacks.
Workspace isolation by configuring Allow Hostnames is a counter measure against client side attacks that attempt to cross workspace boundaries. This security measure is not necessary if you trust all applications that are accessible using the instance's host which includes applications that are written in other frameworks and languages such as Oracle Application Development Framework (ADF) and Java.
See Also:
"Isolating a Workspace to Prevent Browser Attacks" and "Isolating All Workspaces in an Instance" in Oracle Application Express Administration GuideBy 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
Developers can configure session time out for a specific application, or administrators can configure sessions time out for an entire instance.
See Also:
"Session Management" to learn how to configure these attributes at an application-level. To configure these attributes for an entire Oracle Application Express instance, see "Configuring Session Timeout" 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:
On Windows:
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
Tip:
TheAPEX_ADMINISTRATOR_ROLE must be granted directly to a user and not through another database role.Execute the following statement:
ALTER SESSION SET CURRENT_SCHEMA = APEX_050000;
Execute the following statement:
BEGIN
APEX_INSTANCE_ADMIN.SET_PARAMETER('PASSWORD_HISTORY_DAYS',365);
COMMIT;
END;
/
This restricts 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 theAPEX_UTIL.STRONG_PASSWORD_CHECK procedure and the APEX_UTIL.STRONG_PASSWORD_VALIDATION function described in Oracle Application Express API Reference.Disabling the Allow SQL Websheet attribute enables administrators to prevent Websheet users from accessing underlying database objects using SQL tags or from creating SQL reports.
See Also:
"Enabling and Disabling SQL Access in Websheets" in Oracle Application Express Administration GuideDisabling the Enable RESTful Services attribute prevents developers from creating and editing RESTful Web Services mapped to SQL and PL/SQL in conjunction with Oracle REST Data Services 2.0 or later.
See Also:
"Controlling RESTful Services for an Instance" in Oracle Application Express Administration GuideThis section provides a summary of security best practices when configuring an Oracle Application Express instance.
See Also:
"Configuring Instance Settings" in Oracle Application Express Administration GuideAdministrators determine the amount of automation when provisioning (or creating) new workspaces. To determine how provisioning works, an Instance Administrator selects one of the following options on the Instance Settings page:
Manual - The administrator creates new workspaces and manually notifies the Workspace administrator of the login information.
Request - Users request workspaces directly in a self-service fashion.
Request with Email Verification - In this mode, users request workspaces directly by clicking a link on the login page to access a request form. Each user receives an initial email containing a verification link. When the user clicks the verification link, the request is processed. The user can then access the workspace using the Sign In page.
See Also:
"About Specifying How Workspaces Are Created" in Oracle Application Express Administration GuideIn order to send email from an Oracle Application Express application, an Instance administrator must define the email SMTP settings and set the Use SSL/TLS attribute to use a secure connection for Oracle Database 11gR2 or later.
See Also:
"Configuring Email" in Oracle Application Express Administration Guide and "When and Why Network Services Must be Enabled"Administrators can configure the following storage options: require a new schema when requesting a workspace, auto extend tablespaces, or delete uploaded files are a specified number of days.
See Also:
"Configuring Storage" in Oracle Application Express Administration GuideA wallet is a password-protected container that stores authentication and signing credentials (including private keys, certificates, and trusted certificates) needed by SSL. You must create a wallet if you:
Call a SSL-enabled URL (for example, by invoking a Web service).
Create a region of type URL that is SSL-enabled.
Configure secure SMTP by setting the Use SSL/TLS attribute to Yes.
Have applications with LDAP authentication schemes that are configured to use SSL with Authentication.
See Also:
"Configuring Wallet Information" in Oracle Application Express Administration GuideInactive workspaces consume valuable storage space and degrade system performance. By enabling Workspace Purge Settings, administrators can configure Oracle Application Express to purge inactive workspaces.
See Also:
"Purging Inactive Workspaces" in Oracle Application Express Administration GuideThis section provides a summary of security best practices when managing workspaces in Oracle Application Express.
See Also:
"Managing Existing Workspaces" in Oracle Application Express Administration GuideWhen users log in to Oracle Application Express, they log in to a shared work area called a workspace. Each workspace can have multiple associated (or mapped) schemas. Instance administrators can define associations between workspaces and schemas as appropriate. By associating a workspace with a schema, developers in that workspace can create new database objects in that schema and build applications that interact with the database objects in that schema.
See Also:
"Managing Workspace to Schema Assignments" in Oracle Application Express Administration GuideAdministrators can define what schemas specific users have access to and also their user role, that is if they are a workspace administrator, a developer, or an end user. Administrators can also limit developer access to specific Application Express components and lock accounts. Oracle Application Express includes two separate interfaces for managing developers and users. Workspace administrators manage user accounts within their workspace and Instance administrators manage all user accounts across an Application Express development instance.
See Also:
"Managing Users Across an Application Express Instance" and "Managing Users in a Workspace" in Oracle Application Express Administration GuideWorkspace administrators can control user access to key components such as Application Builder, Team Development, SQL Workshop, and PL/SQL editing, which determines whether developers have the ability to edit and compile PL/SQL program units from Object Browser. For example, suppose an administrator wants users to be able to build database components, run SQL statements, but not create applications, he or she could define a workspace with rights to a specific schema and then configure the users as developers using the options on the Set Workspace Preferences page.
See Also:
"Configuring Workspace Preferences" in Oracle Application Express Administration GuideOracle 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.
See Also:
"Configuring Wallet Information" and "Configuring Report Printing" in Oracle Application Express Administration GuideAn Oracle Application Express runtime environment enables you to run production applications, but 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:
"Installing Exported Applications into a Runtime Environment" in Oracle Application Express Administration GuideThis section describes how to enable network services in Oracle Database 11g or later.
By default, the ability to interact with network services is disabled in Oracle Database 11g Release 1 or 2 or later. Therefore, if you are running Oracle Application Express with Oracle Database 11g Release 1 or 2 or later, you must use the new DBMS_NETWORK_ACL_ADMIN package to grant connect privileges to any host for the APEX_050000 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.
PDF report printing.
Tip:
To run the examples described in this section, the compatible initialization parameter of the database must be set to at least 11.1.0.0.0. By default Oracle Database 11g or 12c will already has the parameter set properly, but a database upgraded to Oracle Database 12c 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 any host for the APEX_050000 database user. This example assumes you connected to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role.
DECLARE
ACL_PATH VARCHAR2(4000);
ACL_ID RAW(16);
BEGIN
-- Look for the ACL currently assigned to '*' and give APEX_050000
-- the "connect" privilege if APEX_050000 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;
-- Before checking the privilege, ensure that the ACL is valid
-- (for example, does not contain stale references to dropped users).
-- If it does, the following exception will be raised:
--
-- ORA-44416: Invalid ACL: Unresolved principal 'APEX_050000'
-- ORA-06512: at "XDB.DBMS_XDBZ", line ...
--
SELECT SYS_OP_R2O(extractValue(P.RES, '/Resource/XMLRef')) INTO ACL_ID
FROM XDB.XDB$ACL A, PATH_VIEW P
WHERE extractValue(P.RES, '/Resource/XMLRef') = REF(A) AND
EQUALS_PATH(P.RES, ACL_PATH) = 1;
DBMS_XDBZ.ValidateACL(ACL_ID);
IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'APEX_050000',
'connect') IS NULL THEN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH,
'APEX_050000', 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_050000', TRUE, 'connect');
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*');
END;
/
COMMIT;
The following example demonstrates how to provide less privileged access to local network resources. This example enables access to servers on the local host only, such as email and report servers.
DECLARE
ACL_PATH VARCHAR2(4000);
ACL_ID RAW(16);
BEGIN
-- Look for the ACL currently assigned to 'localhost' and give APEX_050000
-- the "connect" privilege if APEX_050000 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;
-- Before checking the privilege, ensure that the ACL is valid
-- (for example, does not contain stale references to dropped users).
-- If it does, the following exception will be raised:
--
-- ORA-44416: Invalid ACL: Unresolved principal 'APEX_050000'
-- ORA-06512: at "XDB.DBMS_XDBZ", line ...
--
SELECT SYS_OP_R2O(extractValue(P.RES, '/Resource/XMLRef')) INTO ACL_ID
FROM XDB.XDB$ACL A, PATH_VIEW P
WHERE extractValue(P.RES, '/Resource/XMLRef') = REF(A) AND
EQUALS_PATH(P.RES, ACL_PATH) = 1;
DBMS_XDBZ.ValidateACL(ACL_ID);
IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'APEX_050000',
'connect') IS NULL THEN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH,
'APEX_050000', 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 power users to connect to everywhere',
'APEX_050000', TRUE, 'connect');
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('local-access-users.xml','localhost');
END;
/
COMMIT;
Procedures CREATE_ACL, ASSIGN_ACL, ADD_PRIVILEGE and CHECK_PRIVILEGE in DBMS_NETWORK_ACL_ADMIN are deprecated in Oracle Database 12c. Oracle recommends using APPEND_HOST_ACE instead. The following example demonstrates how to grant connect privileges to any host for the APEX_050000 database user. This example assumes you connected to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role.
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host => '*',
ace => xs$ace_type(privilege_list => xs$name_list('connect'),
principal_name => 'apex_050000',
principal_type => xs_acl.ptype_db));
END;
/
The following example demonstrates how to provide less privileged access to local network resources. This example enables access to servers on the local host only, such as email and report servers.
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host => 'localhost',
ace => xs$ace_type(privilege_list => xs$name_list('connect'),
principal_name => 'apex_050000',
principal_type => xs_acl.ptype_db));
END;
/
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_050000 user. See "Granting Connect Privileges Prior to Oracle Database 12c."