20.1.3 Managing Instance Security

Learn about security best practices when managing an Oracle APEX instance.

Note:

To ensure the security and performance of your development environment, this functionality is not available in Oracle APEX instances running in Oracle Cloud.

See Also:

Configuring Security in Oracle APEX Administration Guide

20.1.3.1 About Creating Login Controls

Administrators can configure login controls for an entire instance or for individual workspaces.

Workspace administrators and developers can create user accounts for the purpose of logging in to the APEX development environment and for end-user authentication to applications developed within their workspaces.

Administrators can configure login controls at the instance or workspace level. For example, if an Instance administrator configures account login controls in APEX Administration Services, that configuration applies to all APEX 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).

20.1.3.2 About Enabling Public File Upload

Administrators can use the Allow Public File Upload attribute to control whether unauthenticated users can upload files in applications that provide file upload capability

See Also:

Controlling Public File Upload in Oracle APEX Administration Guide

20.1.3.3 About Restricting User Access by IP Address

Administrators can restrict user access to an APEX 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 APEX Administration Guide

20.1.3.4 About Specifying an Instance Proxy

Administrators can use the Instance Proxy attribute to configure an entire APEX 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 APEX Administration Guide

20.1.3.5 About Utilizing Secure Sockets Layer

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 APEX 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 APEX 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 App 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 APEX development and administration applications) to require HTTPS.
  • Development and Administration - Forces all internal applications within APEX (that is, App Builder, SQL Workshop, Instance Administration and so on) to require HTTPS.
  • Application specific - Makes HTTPS dependent on application-level settings.

See Also:

Configuring HTTP Protocol Attributes in Oracle APEX Administration Guide

20.1.3.6 About Enabling RESTful Access

Administrators can use the Allow RESTful Access attribute to control whether developers can expose report regions as RESTful services.

See Also:

Enabling RESTful Services for an Instance in Oracle APEX Administration Guide

20.1.3.7 About Rejoin Sessions

Use the Rejoin Sessions attribute to control if APEX supports application URLs that do not contain session IDs.

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.

When rejoin sessions is enabled, APEX 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, APEX 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 APEX 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.

20.1.3.8 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 APEX 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:

20.1.3.9 About Utilizing Session Timeout

Configure Session Timeout attributes to 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
  • Maximum Session Idle Time in Seconds
  • Session Timeout Warning in Seconds
  • Session Timeout URL (application-level setting)
  • Idle Timeout URL (application-level setting)

Developers can configure session timeout for a specific application, or administrators can configure sessions timeout for a workspace or an entire instance.

See Also:

20.1.3.10 Restricting Password Reuse

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:

  1. Start SQL*Plus and connect to the database where APEX 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:

    The APEX_ADMINISTRATOR_ROLE must be granted directly to a user and not through another database role.

  2. Execute the following statement:
    ALTER SESSION SET CURRENT_SCHEMA = APEX_220100;
    
    
  3. 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 APEX.

  4. 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;
    /
    

See Also:

20.1.3.11 About Enabling RESTful Services

Administrators can control the ability to create and access RESTful Services at either the workspace or instance-level.

Disabling 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.

To configure Enable RESTful Services:

  • In Workspace Administration — Sign in to APEX and click the Administration menu. Select Manage Service, Set Workspace Preferences, SQL Workshop and find the Enable RESTful Services attribute.
  • In Instance Administration — Sign in to APEX Administration Services. Under Instance Settings, click Feature Configuration and click Feature Configuration. Find the REST tab and then Enable RESTful Services attribute.