454 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence As you can see, the SSL port at the time of install was 4458. I changed this port in ssl.conf to 443, but this change will not show up in portlist.ini. Additionally, if you want to list the ports that OHS is listening on from a bash shell, the following command will show all ports in use by the HTTPD process: $ sudo netstat -tnlp | grep httpd tcp 0 0 127.0.0.1:7202 0.0.0.0:* LISTEN 5830/httpd tcp 0 0 :::7780 :::* LISTEN 5830/httpd tcp 0 0 :::443 :::* LISTEN 5830/httpd This does not tell you what type of traffic the ports are listening for, but it is useful for a quick reminder of the ports in use without your having to dig too deep into the file system to find ssl. con. Keep in mind that HTTPD is the process name for Apache-based HTTP servers, so if you’re running more than one HTTP server that uses Apache, you will see all the ports from all of the Apache instances. Now that you know what port to test, let’s test an HTTPS connection from a web browser by entering https://machine-name:443/ in a web browser to display the OHS home page (substituting your actual values for machine-name and port, which is 443 in this case). If we were using the default wallet, the browser should display a warning that this certificate is not valid. The certificate actually fails all three criteria, in that it is expired, the domain name listed does not match our domain, and it is not signed by a trusted Certificate Authority. For testing purposes, however, this is fine. SSL and APEX Now that we have verified that SSL is working correctly, let’s configure an APEX application using two different scenarios regarding SSL. The goal of the first scenario is to switch to HTTPS for the login page of an application, and then switch back to HTTP for subsequent requests. We want to encrypt the usernames and passwords sent over the network from the login page, but the company policy allows internal traffic to be unencrypted, so the application will switch back to unencrypted HTTP requests once a user is logged in. The configuration for this scenario is all done inside our APEX application and requires no additional steps for OHS. We will use two application processes: one to enable HTTPS and one to enable HTTP. The conditions for firing these processes reference page 101, as 101 is the login page of our application. The following is the first application process used to change from the HTTPS protocol to the HTTP protocol for all pages except page 101 (which is shown in Figure 11-8): This code goes in the block of an Application Process htp.init; owa_util.mime_header('text/html', FALSE); htp.p('Location: http://'|| owa_util.get_cgi_env('SERVER_NAME')|| ':7780'|| owa_util.get_cgi_env('SCRIPT_NAME') || owa_util.get_cgi_env('PATH_INFO')||'?'|| owa_util.get_cgi_env('QUERY_STRING')); owa_util.http_header_close; The following are attributes of the process Sequence: 1 Condition Type: PL/SQL Process Condition Text: owa_util.get_cgi_env('REQUEST_PROTOCOL') = 'HTTPS' and :APP_ PAGE_ID != 101 Chapter 11: Web-centric Security in APEX 455 In summary, the process condition checks to see whether the protocol is HTTPS and the page is not 101; it then redirects to the same URL, but substitutes HTTP for HTTPS and appends the non-SSL port to the SERVER_NAME variable. You should change the port number, currently 7780, and login page number, currently 101, to reflect the proper values for your environment. The purpose of our next application process is to switch to HTTPS for the login page: This code goes in the block of an Application Process htp.init; owa_util.mime_header('text/html', FALSE); htp.p('Location: https://'|| FIGURE 11-8 Application process to switch to HTTP 456 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence owa_util.get_cgi_env('SERVER_NAME')|| ':443'|| owa_util.get_cgi_env('SCRIPT_NAME') || owa_util.get_cgi_env('PATH_INFO')||'?'|| owa_util.get_cgi_env('QUERY_STRING')); owa_util.http_header_close; The following are attributes of the process Sequence: 2 Condition Type: PL/SQL Process Condition Text: owa_util.get_cgi_env('REQUEST_PROTOCOL') = 'HTTP' and :APP_PAGE_ ID = 101 Note that our HTTPS port is 443, but your HTTPS port may be different, so make sure you edit this process to match the configuration of your environment. If you are using the default ports of 80 for HTTP and 443 for HTTPS, you can simply omit the line in each process that adds the port. Now run your application to test it. The login page should seamlessly redirect to HTTPS. Once you log in with valid credentials, you will see the URL change to HTTP and the corresponding HTTP port. This scenario requires that you add these processes to each application. mod_rewrite and SSL Apache mod_rewrite is also a powerful tool to conditionally require HTTPS. A word of caution about mod_rewrite: Its directives affect the whole HTTP server. Developing a directive often takes a number of test cases and more than a few tries to get right, and it requires a restart of the HTTP server for each change to take effect. As such, it’s not a good idea to test any directives on an HTTP server that is in use by other developers and a terrible idea to test it on a production server. Fortunately it’s easy to install another HTTP server and configure it to point at the same APEX installation without impacting other users. The following directive simply redirects all non-HTTPS requests to HTTPS and our HTTPS port: RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^.*$ https://%{SERVER_NAME}:443%{REQUEST_URI} [R,L] Another option is to redirect to HTTPS for all applications that are not the APEX development environment: RewriteCond %{HTTPS} !=on RewriteCond %{REQUEST_URI}%{QUERY_STRING} /pls/apex/f?p=.* RewriteCond %{REQUEST_URI}%{QUERY_STRING} !/pls/apex/f?p=(4[0-9]{3}:.*) RewriteRule ^.*$ https://%{SERVER_NAME}:443%{REQUEST_URI} [R,L]We can also enable HTTPS for a specific subset of applications. In the following example OHS will redirect to HTTPS for applications 111,222,333 and 444.RewriteCond %{HTTPS} !=on RewriteCond %{REQUEST_URI}%{QUERY_STRING} /pls/apex/f?p=(111|222|333|444):.* RewriteRule ^.*$ https://%{SERVER_NAME}:443%{REQUEST_URI} [R,L] Protecting the APEX Database Schemas As discussed earlier in this chapter, all code and metadata for APEX are installed in two schemas in the database. In versions prior to APEX 3.2 the schemas followed the pattern FLOWS_FILES and FLOWS_XXXXXX (FLOWS_030100 for APEX 3.1). With the introduction of Application Express 3.2, the primary schema now follows the pattern APEX_XXXXXX (APEX_030200 for APEX 3.2). Chapter 11: Web-centric Security in APEX 457 The primary APEX schema, APEX_XXXXXX, is granted several system-level privileges that could allow an attacker to execute malicious DML and DDL against any other schema in the database. This schema should be treated with the caution that a security-conscious DBA would afford the SYSTEM schema. As such, this schema is locked by default at the end of the APEX installation, and it should always remain locked. A few operations may require that you unlock this account for a very short period of time, such as modifying instance settings from the command line or resetting the admin password. However, most if not all of these operations could be performed by another user account that has been granted the APEX_ADMINISTRATOR_ROLE. We’ll discuss Database Vault later in this section, as it provides a much more robust alternative for protecting privileged accounts. Any periodic security audits conducted against a database where APEX is installed should check to make sure this account is still locked. There is no reason that developers or DBAs should connect to any of the APEX_ or FLOWS_ schemas on a regular basis, as this opens up unnecessary security risks in addition to making it very easy for someone to issue a command accidentally that could irreparably damage an APEX installation. The tables and packages in the FLOWS_ and APEX_ schemas should be treated like any other data dictionary objects—that is, as untouchable. Companies often employ a segregation of duty policy that may force the separation of the APEX schemas from the data the APEX applications will serve. This is especially true when highly sensitive data or personally identifiable information (PII) is involved. For this reason, some developers choose to install APEX in a database that’s different from the database where their sensitive data is stored. This technique does provide physical separation of the data and the development tool, but it is little more than a perfunctory measure that also adds a lot of inconvenience to developers. For APEX to access data in another database, a database link must be created to allow queries in one database to access tables in another. There are three problems with this solution that typically relegate it to a measure of last resort: The first problem is that in an online transaction processing (OLTP) environment with a lot of subsecond queries, database links can add a tremendous amount of latency to a system, even if both databases are on the same Gigabit network switch. The second problem with database links relates to the APEX development environment. The wizards used to build APEX components such as reports or forms will only work with local database objects, not objects accessed over database links. For these wizards to create APEX controls for objects in remote databases, local synonyms or views must be created for all remote objects. Finally, the creation of the database link effectively creates a bridge between the two databases, thus subverting much of the intended security gain expected by separating them in the first place. Database Vault and APEX Oracle Database Vault is the best mechanism for securing the database tier of an APEX instance while still allowing developers to be productive. One of the primary benefits of Database Vault is that it limits the power of overprivileged accounts and mitigates, if not eliminates, privilege abuse. We stated earlier that the privileges associated with the APEX_XXXXXX schema are similar to those for SYSTEM, so Database Vault is a logical choice when looking for a solution to securing this account. APEX cannot be installed in a database when Database Vault is enabled, and it will not run without adding some command rules. Disabling Database Vault requires that you relink the database using specific parameters. To install APEX in a Database Vault database, do the following: 1. Disable Database Vault. 2. Install or upgrade APEX. 458 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence 3. Enable Database Vault. 4. Execute command rules to allow APEX to function. The following code can be used to disable Database Vault: # Disable Database Vault # Shutdown the Database using SQL*Plus cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk dv_off cd $ORACLE_HOME/bin relink oracle # Startup the Database using SQL*Plus # Install or Upgrade Application Express # Enable Database Vault # Shutdown the Database using SQL*Plus cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk dv_on cd $ORACLE_HOME/bin relink oracle # Startup the Database using SQL*Plus The following list details the command rules that should be executed once APEX is installed and Database Vault is enabled: connect dv_owner begin dbms_macadm.add_auth_to_realm( realm_name => 'Oracle DataDictionary', grantee => 'APEX_PUBLIC_USER', rule_set_name => null, auth_options => dbms_macutl.g_realm_auth_owner); end; / begin dbms_macadm.update_command_rule (command => 'CREATE USER', rule_set_name => 'Can Maintain Accounts/Profiles', object_owner => '%', object_name => '%', enabled => dbms_macutl.g_yes); end; / begin dbms_macadm.update_command_rule (command => 'ALTER USER', rule_set_name => 'Can Maintain Own Account', object_owner => '%', object_name => '%', enabled => dbms_macutl.g_yes); end; / Chapter 11: Web-centric Security in APEX 459 Once APEX is installed and the database is relinked with Database Vault enabled, APEX can no longer provision new workspaces with a new schema. Create User is a protected role and is limited to the Database Vault Manager account. To provision a new APEX workspace that requires a new schema, do this: 1. Ask the Database Vault Manager to create a new schema. 2. Log into the APEX Administration application. 3. Provision a new workspace using an existing schema. This separation of duties requires that the Database Vault manager and the APEX administrator coordinate when a new project is started. While this may seem like a barrier to productivity to some, it actually creates a perfect opportunity for the people responsible for the security of the data and the people developing applications that access that data to communicate and ensure that both parties agree on the use of this data. This also prevents the possibility of someone connecting to as the APEX schema, creating another privileged account, and then using that account to gain access to sensitive data. Summary APEX is built on a unique architecture that tightly couples the application and the data. Understanding this architecture, including its strengths, weaknesses, and nuances, is essential to deploying APEX in a secure configuration. The APEX development team has gone to great lengths to make it as secure as possible out of the box, as is evidenced by the many security enhancements in APEX 3.2. However, an APEX administrator has many choices to make in the areas of topology and configuration that will ultimately determine the security of the environment. This chapter provided solutions to protect the APEX environment as a whole, before a developer writes a single line of code. Once the environment is secure, the focus can shift to securing the applications built in that environment. This page intentionally left blank CHAPTER 12 Secure Coding Practices in APEX 461 462 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence his chapter shifts focus from securing the Application Express environment to securing an individual application. The concepts involved in creating a secure application using APEX are very similar to those of other database-centric technologies. Data should be secured at the lowest level possible using techniques such as Virtual Private Database (VPD), Oracle Label Security (OLS), Programmatic Encryption, and Transparent Data Encryption (TDE). End users must be authenticated against some credential store, such as an Lightweight Directory Access Protocol (LDAP) directory or Oracle Access Manager. A user’s authorization rights or privileges should also be pulled from a central source such as Oracle Access Manager (OAM). As discussed in Chapter 11, APEX handles identity preservation out of the box, but it is a developer’s responsibility to understand and leverage this feature. Security-conscious developers should also consider other technologies that will access the same data and construct security policies such that the rules are defined and enforced in one place, not spread out across all the systems that access the data. Chapter 11 provided information about APEX’s architecture and concepts to lay the foundation for the concepts introduced in this chapter. The more developers understand these technologies, the better prepared they are to secure them. Authentication and Authorization Authentication is the process of identifying users and proving they are who they claim to be. In the case of your username and password, the username defines your identity, and the password is the proof that you are who you say you are. Identification can also be verified using other techniques such as certificates or biometric devices. Once the system authenticates and identifies the user, the process of authorization can occur. Authorization determines what rights and privileges a user has within an application. Database roles are a well know example of authorization, as they are used to define what objects a user can access and what actions the user can perform. Authorization can also be defined in many other places, such as in a database table or an LDAP directory. Authentication and authorization are both defined as application-level attributes in APEX. The definition of authentication and authorization schemes are decoupled from the individual pages and objects within an APEX application, which makes them easy to redefine as requirements change. Authentication Schemes Authentication schemes are declarative constructs in APEX that allow a developer to define how users will authenticate to the application. You can think of them as a way to determine who a user is. A typical authentication scheme accepts a username and password and then validate those credentials against an internal or external source. An authentication scheme is defined at the application level, and an application can have only one current authentication scheme. It is common, however, for an application to have several authentication schemes that are used in different environments, such as development and production. A developer can simply change which authentication scheme is current before moving the application from the development environment to production. It is not possible to switch between authentication schemes at runtime, to have more than one current authentication scheme, or to use different authentication schemes for different pages within the same application. In rare cases when it is necessary to authenticate against multiple sources, such as either LDAP or database credentials, this logic must be written into a single custom authentication scheme. T Chapter 12: Secure Coding Practices in APEX 463 APEX includes several preconfigured authentication schemes including LDAP, Database Credentials, Oracle Single Sign-On (SSO), and APEX Credentials. These are well documented and plenty of examples of these schemes are publicly available. We’ll focus on several custom authentication schemes to supplement the built-in authentication schemes. Custom Table of Usernames and Passwords One of the most common questions around authentication schemes in the APEX community is how to use a simple table of usernames and passwords for authentication. In general, I strongly advise developers to leverage an identity management solution such as Oracle Access Manager, because it provides many benefits, not the least of which is the ability to authenticate many systems, not just an APEX application. However, this question is asked so often that it is beneficial to provide an example here. It is also a great opportunity to demonstrate the use of the DBMS_CRYPTO package in the context of APEX. One of the key concepts to take away from this example is this: Never store passwords in clear text. Many people use the same password or subset of passwords for all applications. This means it is very likely that at least some of the username/password sets stored in your table could also be used to access a person’s online applications, including financial institutions. This scenario was the subject of several high-visibility data breaches and represents a very real security risk. The question is, How do you securely store a password in a database table? The answer: You don’t store it at all; you store a cryptographic hash of the password instead. This is exactly how the Oracle Database and APEX authenticate users. Here’s how this solution works: 1. A password is run through a one-way hash algorithm and the resulting value is stored in the table. For example, let’s say the user’s password is welcome and the hash of welcome is #H*8F@90. 2. When a user attempts to log into the application, she enters the password of elcome. 3. This password is run through the same one-way hash algorithm. The resulting hash is Z;&R3!. 4. We then compare the two hash values. Since they are not equal, authentication fails. 5. The user now enters the correct password of welcome. 6. The resulting hash of welcome is #H*8F@90, which is then compared to the hash stored in the table. 7. Since #H*8F@90 = #H*8F@90, the user is now authenticated. In this example, the term “hash” was used for brevity. The reality is that the hash algorithms included with most software distributions, including the DBMS_CRYPTO package, are well known. As such, an attacker could generate a table of common passwords and their corresponding hash values. If the attacker gains access to a table, he would probably be able to determine one or more passwords by matching the stored hash with his table of hash values. To combat this threat, our example will use a message authentication code (MAC) algorithm. These algorithms also take in a key to generate the hash, so an attacker must know both the algorithm and the key to get access. Using a sufficiently long and random key will all but eliminate this threat. You should store this key in a secure location that is not on the server running the database. If this key is compromised, it will be significantly easier for an attacker to generate a hash table and compromise passwords. . Database Vault database, do the following: 1. Disable Database Vault. 2. Install or upgrade APEX. 458 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence 3. Enable Database. cannot be installed in a database when Database Vault is enabled, and it will not run without adding some command rules. Disabling Database Vault requires that you relink the database using specific. dv_off cd $ORACLE_ HOME/bin relink oracle # Startup the Database using SQL*Plus # Install or Upgrade Application Express # Enable Database Vault # Shutdown the Database using SQL*Plus cd $ORACLE_ HOME/rdbms/lib make