3.4.5 Isolating All Workspaces in an Instance

Instance administrators can configure limits to isolate all workspaces and prevent browser attacks. Workspace administrators can override these default values at the workspace-level.

Note:

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

• About Isolating Workspaces to Prevent Browser Attacks
  Isolating workspaces is an effective approach to preventing browser attacks.
• Configuring Instance-Level Workspace Isolation Attributes
  Configure isolation and resource limitation default values for all workspaces in an instance.

3.4.5.1 About Isolating Workspaces to Prevent Browser Attacks

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

Instance administrators can cofigure the Allow Hostnames attribute at the instance-level. Workspace administrators can override the instance-level setting for a specific workspace.

See Also:

"Isolating a Workspace to Prevent Browser Attacks"

3.4.5.2 Configuring Instance-Level Workspace Isolation Attributes

Configure isolation and resource limitation default values for all workspaces in an instance.

Tip:

Workspace administrators can override these default values at the workspace-level. See "Isolating a Workspace to Prevent Browser Attacks."

To configure instance-level Workspace Isolation attributes:

1. Sign in to Oracle Application Express Administration Services.
2. Click Manage Instance.
3. Under Instance Settings, click Security.
4. Under Workspace Isolation, configure the following attributes:

   Tip:

   To learn more about an attribute, see field-level Help.

   Table 3-1 Workspace Isolation Attributes

   Attribute	Description
   Allow Hostnames	Enter a comma separated list of hostnames that can be used to access this instance. This attribute can be used to specify which DNS aliases of the web server can be used with applications. You can configure specific values that override this one at workspace level. If you enter one or more hostnames, the incoming HTTP request URL's hostname part must match one of the listed hostnames. For example, you can register the DNS alias hr.example.com for your web server www.example.com. The instance value of Allowed Hostnames can be set to www.example.com. If you then set the HR workspace's Allow Hostnames to hr.example.com, users have to access HR applications using hr.example.com and all other applications of this instance using www.example.com. With this configuration, the browser's Same Origin security policy provides a client-side barrier between HR applications and other applications of the instance, which run in another browser tab or window.
   Resource Consumer Group	Specify the Database Resource Manager consumer group to be used for all page events on the instance. The Resource Consumer Group provides more control of hardware resources such as CPU and I/O requests. Workspace-level settings override instance-level settings to enable administrators to provide more or less resources depending on the needs or importance of a workspace. At the beginning of every request, the Application Express engine switches the current consumer group of the current database session to the consumer group that is defined at workspace or instance-level. This applies to both executing applications and any of the applications used within the Application Express development environment. These limitations apply to all page requests where application code executes using the Application Express engine which enables the assigned Resource Manager settings. However, these limitations do not apply to Oracle Scheduler jobs that workspace developers create, or to ORDS REST requests, where Application Express is not in the code path. A call to set the workspace, such as apex_util.set_workspace('MY_WORKSPACE'); at the beginning of the scheduler job, enables the right consumer group. However, there is often no reason for developers to add this type call. Therefore, administrators should apply the Resource Manager consumer groups to both the Application Express workspaces and to the workspace schemas (that is, the underlying database users). You must grant privilege to switch to a consumer group to either PUBLIC or the Application Express schema. This privilege is typically granted using the procedure DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP. See Also: "Managing Resources with Oracle Database Resource Manager" in Oracle Database Administrator’s Guide
   Maximum Concurrent Workspace Requests	Enter the maximum number of concurrent page events that Oracle Application Express supports for all applications. You can configure a specific value at the workspace-level. Instead of processing a page event, Oracle Application Express shows an error message when the limit is already reached. Oracle Application Express keeps track of workspace requests by querying the CLIENT_INFO column of GV$SESSION. This tracking will not work if developers overwrite CLIENT_INFO, for example, with a call to DBMS_APPLICATION_INFO.SET_CLIENT_INFO.
   Maximum Concurrent Session Requests	Enter the maximum number of concurrent page events that Oracle Application Express supports for each session for applications in this instance. You can configure a specific value at the workspace-level. Instead of processing a new page event, Oracle Application Express shows an error message when the limit is already reached. Alternatively, you can use the Concurrent Session Requests Kill Timeout attribute to kill an active database session, to process the new page event. Oracle Application Express keeps track of session requests by querying the CLIENT_IDENTIFIER column of GV$SESSION. This tracking will not work if developers overwrite CLIENT_IDENTIFIER, for example, with a call to DBMS_SESSION.SET_IDENTIFIER.
   Concurrent Session Requests Kill Timeout	If a new page event comes in that is outside the limits of Maximum Concurrent Session Requests, Oracle Application Express can execute alter system kill session on the oldest active database session which processes another page event for this Application Express session. The Concurrent Session Requests Kill Timeout attribute specifies the number of seconds a database process has to be active, before it can be killed. If you leave this attribute empty, Application Express will not kill any database sessions. Warning: Killing sessions can cause problems with the application server's database session pool.
   Maximum Size of Files in Workspace	Enter the total size (in bytes) of all files that can be uploaded to a workspace. You can configure a specific value at the workspace-level.
   Maximum Web Service Requests	Enter the maximum number of web service requests that Application Express supports for each workspace in this instance. You can configure a more specific value at the workspace-level.

5. Click Apply Changes.