APEX Lockdown: Securing the XDB Protocol Server

This is hopefully one of the first posts about how to secure, setup, a proper APEX environment seen from a DBA perspective. Because this website is mainly about XMLDB, it is also about the XDB protocol server and currently not about using Apache or the (apparently another way of doing things) new upcoming APEX Listener.

The behavior of the XDB Protocol Server is controlled by its xdbconfig.xml file. This xdbconfig.xml file is restricted to an XML Schema called xdbconfig.xsd. Both can be found in the XMLDB folders. The xdbconfig.xml can be found in the root folder. The xdbconfig.xsd file is part of Oracle XML Schemata and can be found in the /sys/schemas/PUBLIC/xmlns.oracle.com/xdb/ folder.

The xdbconfig.xml and xdbconfig.xsd files are, as all files and folders in XMLDB, secured/controlled via Access Control Lists, ACL files. The xdbconfig.xml file is controlled via the /sys/acls/all_owner_acl.xml ACL file. The xdbconfig.xsd file is controlled via the /sys/acls/bootstrap_acl.xml ACL file.

The security ACL settings for those files (resources as files and folders are called in XMLDB):

all_owner_acl.xml:

Principal       Privilege
-------------   ---------
dav:owner	all

bootstrap_acl.xml:

Principal       Privilege
-------------   ---------
dav:owner	all
XDBADMIN	all
PUBLIC		resolve

The bootstrap_acl.xml file is protected by itself, but I will come back on ACL, ACE’s and XBD security,etc, in different post.

If APEX is not installed, if APEX is not enabled via the protocol server then the following functionality (“servlets” as they are called) are active, if the protocol server is enabled:

• TestServlet
• DBURIServlet
• ReportFmwkServlet

The TestServlet is an demo, code example, that is referenced in the Oracle XMLDB Developers Guide, and shouldn’t be there in the first place.

The DBUriServlet works the same as the DBUri URIType, an Uniform Resource Identifier, and can be used to access data in the (relational) database. This functionality alone is an security issue you shouldn’t underestimate. It is particularly vulnerable for DOS methods in older database versions.

The ReportFmwkServlet somehow hooks into DB Console and/or APEX, but I still have figured that one out and also it is not documented. My last attempt to figure it out wasn’t fully successful.

Disabling Protocol Server Behavior

To disable these “servlets”, you can delete their servlet and servlet mappings in the xdbconfig.xml file. In principle you will have to delete their global element structures. In Oracle 11gR1 you have two options to do this.

1. Make a backup copy of the xdbconfig.xml file (inside or outside the database). Alter the file too your liking (be aware that it should validate against its XML Schema xdbconfig.xsd – you could use the online XML Schema Validator) and replace the original one with the (by you) altered xdbconfig.xml file.
2. Use the new, in 11gR1 and upwards, available DBMS_XDB procedures.

Whatever you do, be aware that it is tricky and could result in an broken Protocol Server functionality. Flavio has written a good post (ORA-31114: XDB configuration has been deleted or is corrupted) what to do if it happens to you. The main principle here is that if you alter the xdbconfig.xml, then it should validate against the xdbconfig.xsd XML Schema. If it doesn’t and you place it back, overwrite the original, then you will be in trouble. So as a good habit of mine dictates. Start with a backup.

Method 2. is demonstrated below:

set long 10000000
set pages 5000
set trimspool on
set feedback on
set verify off

-- Create a backup of the xdbconfig.xml file

create table system.xdb$config
as select * from xdb.xdb$config;

select dbms_metadata.get_ddl('TABLE','XDB$CONFIG','SYSTEM') from dual;
select dbms_metadata.get_ddl('TABLE','XDB$CONFIG','XDB') from dual;

-- Remove unneeded "servlets"

-- Remove the Test servlet
call DBMS_XDB.DELETESERVLET('TestServlet');
call DBMS_XDB.DELETESERVLETMAPPING('TestServlet');
commit;
-- Remove the DBUri servlet
call DBMS_XDB.DELETESERVLET('DBURIServlet');
call DBMS_XDB.DELETESERVLETMAPPING('DBURIServlet');
commit;

-- Remove the ReportForms servlet
call DBMS_XDB.DELETESERVLET('ReportFmwkServlet');
call DBMS_XDB.DELETESERVLETMAPPING('ReportFmwkServlet');
commit;

alter system register;
.

The two dbms_metadata calls are only there to demonstrate that in this case a “CTAS” will not deliver what you would expect (if I am not mistaken, still an outstanding Oracle enhancement request from me). The XDB$CONFIG table created in the SYSTEM schema is an simple XMLType based on CLOB storage, while the original XDB$CONFIG in 11gR1 is an XMLType based on Object Relational storage limited by its XML Schema.

APEX

What remains are the “servlet’s” for APEX with its servlet mappings that is created via the apex_epg_config_core.sql script. The script can be found in the $ORACLE_HOME/apex folder on the server where the database resides.

These servlet’s are:

• PublishedContentServlet: the servlet that controls unauthenticated file access to the images folder
• APEX: the servlet that hooks into DBMS_EPG in the database.

The apxremov.sql script in the $ORACLE_HOME/apex folder, cleans up an APEX environment, except…

The APEX servlet itself…

Maybe something for an enhancement request…after all the servlet is called “APEX”. If APEX has to be removed than at least all remains/all leftovers should go as well. If needed you could build you own servlet entry via the Protocol Server functionality by learning from the APEX servlet…

More can be done, for instance via ACL’s, but that is a post worthy on its own.

HTH.

Marco