What surprises me sometimes is that those deploying and developing an APEX application treat it like a box and do not consider that APEX is written in PL/SQL, uses PL/SQL and is deployed to an Oracle database. Its like they believe that the database security is someone else's problem or they didn't realise that its in a database - with the data!! Sometimes, the Oracle database is a side issue for them; it's not considered in terms of security and the only factor for the customer is that an Oracle database is needed to run APEX so its provided and not secured in any meaningful way
I wanted to do a post now to highlight at a high level the areas that should be considered for securing an APEX application and database when using and deploying APEX in your database. Lets list and discuss briefly:
- Web Based Security: Your APEX application may use JavaScript to enhance its features and operation but Javascript can be the target of attackers through input manipulation for attacks such as Cross Site Scripting (XSS) and more. This point is not just limited to JS but to any web level technology that can be used from APEX
- Webserver and network security: The webserver is likely to be ORDS and it provides the web content to the end users. The security of ORDS must be considered and the network design of the database, ORDS and access must be secured
- APEX Security: The APEX application itself must be secured at the APEX level. This includes user security, profiles, passwords, instance level security, deployment security, APEX database object security, workspace security and more
- APEX Application security: APEX provides security at the application level and allows security of users, authorisation, authentication and page level security. The application in APEX is written as snippets of PL/SQL that are stored in the APEX repository and these also must be written with security in mind and secure web and database coding techniques used
- Supporting PL/SQL: Often the bulk of the APEX application will be written in separate PL/SQL packages called from a thin veneer of PL/SQL in the APEX repository. These packages must be also secured and designed with security in mind. The schema that owns them must be limited in rights and access to he rest of the Oracle database. The PL/SQL must be written with secure coding techniques in mind. This includes avoiding SQL Injection but also managing access to resources and features securely from the applications PL/SQL
- Schema design and security: The schema that owns the PL/SQL of the application must also be designed with security in mind. The data should be held in one schema and application code (PL/SQL) in another (at least) to allow grants to be made between code and data and not a free for all. Least privilege of the schemas must be observed
- Database Level Security: Database level security is a complex topic of course and I have covered the basic areas here many times. At a high level we must patch and harden. These alone will not secure data. We must also then secure the data within the database. This is the biggest part of the task of securing data in an Oracle database. This part includes user access controls, user level privileges and data level privileges.
- Context Based Security: An additional layer that can be applied is to use context based security such as Database Vault, Virtual Private Database, TSDP and more. The normal rights at the database level are granular but Oracle provides extra (often cost based) features that allow more controlled and fine grained security to be applied. We can also create context based security of our own using PL/SQL code, triggers and views. Context based security can also be used at the APEX level as well as the database level
- Audit Trails: There must be well designed and useful audit trails implemented at the database and also at the PL/SQL level and APEX levels so that any potential misuse of the application or data can be captured to make any breach analysis or forensic analysis easier
- OS Security: The operating system that hosts the database must also be secured. There are many layers that are similar to the database and APEX. We must secure defaults, hardening, users and privileges, audit trails and more
- Admin and User Access: We also must consider how users and particularly types of admin users (sys admins, DBA, support etc) access the OS, the Oracle database and APEX. We must ensure that data is protected through these types of access and that the access is audited
Attacks are many and varied from the web level to abusing APEX itself or abusing the PL/SQL or database or even OS level. Securing an APEX application is multi-layered and we must consider all layers for security when we deploy an APEX application from OS to web.
In general we can take the same approach with each layer:
- Review existing security policies
- Review the actual systems (Database, OS, APEX, PL/SQL)
- Understand the security requirements and design a new policy, update the existing policy, create a fixing strategy
- Fix and secure all systems
- Perform continuous review of all systems (Database, OS, APEX, PL/SQL...)
#oracleace #sym_42 #plsql #apex #oracle #database #security
