mod_rewrite and SSL in Java

Generation QR Code in Java 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 444RewriteCond %{HTTPS} !=on RewriteCond %{REQUEST_URI}%{QUERY_STRING} /pls/apex/f p=(111|222|333|444):* RewriteRule ^*$ https://%{SERVER_NAME}:443%{REQUEST_URI} [R,L]

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 32 the schemas followed the pattern FLOWS_FILES and FLOWS_XXXXXX (FLOWS_030100 for APEX 31) With the introduction of Application Express 32, the primary schema now follows the pattern APEX_XXXXXX (APEX_030200 for APEX 32)

11:

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