A very common question asked is ‘Is APEX Secure?’ and Joel Kallman from Oracle addressed this topic here, the post is a few years old now but it still applies today. There are two levels to this:
The answer to the first question is yes and is still covered by Joel’s blog, but the purpose of this blog is to summarise the latter and discuss the tools and practices you should utilise.
Following on from Rodrigo’s blog a few months ago on Making Your APEX App Safer, we will summarise some of the main practices to follow and tools to use to keep on top of, and also assess, the security of your developed APEX applications.
As the popularity and use of APEX increases, especially for applications based in the cloud potentially accessible by anyone, we can no longer be laid back about the security of applications developed and deployed. Security is a hot topic in the IT world, data breaches make headline news and ‘hacking’ isn’t confined to the very technical or malicious.
We would like the number of potential security vulnerabilities in our applications to be zero but realistically, we are unlikely to be able to achieve that. Even the most critical system (in any technology) that has had huge resources put in to security hardening will still have some potential security risks.
The only fully secure system is one that cannot be accessed at all, but that isn’t realistic either. So, in order to actually provide a functional usable application we have to first accept this, but then use the tools and practices available to ensure we are doing everything in our power and control to build secure web applications.
Oracle has done a great job of providing us with the platform, practices and some tools in order to build secure APEX web applications. However, we must remember firstly to actually use them (correctly) and then to follow the steps outlined below in order to keep the risk of potential vulnerabilities to a minimum.
It is much better if all the tools and practices mentioned here are integrated in to the project lifecycle from day one and then run, analysed, completed, re-assessed and mitigated on a regular basis. Trust us from experience that if ‘Security Testing’ is a step added to the plan after development or even worse, not at all, then providing a secure application will be a much more challenging task.
Authentication and Authorisation
Authentication and authorisation are the ability to control who can access the application, what they can see and what functions they can carry out once authenticated.
APEX includes a number of Preconfigured Authentication Schemes for establishing the identity of a user and you can even build your own Custom Authentication scheme too. Access security is then ultimately defined by the scheme chosen and how it works for checking credentials. Particularly when building your own custom authentication, ensure the scheme adheres to a good password policy and even possibly has multi-factor authentication.
The options for Authorization are very vast but the main thing to highlight around authorization is that consistency is the key in that the authorization should be applied in all places required; there is no use applying an authorization scheme on a menu entry but not then the page the menu entry would direct to. Some of the tools mentioned below will check this for you but if you get in the habit of doing it whilst developing it will quickly become second nature.
Wizards
Entirely functional business applications can be created from a file or from scratch using the provided APEX wizards. In the past, applications created or built this way might not have been as secure as they could have been but this is no longer the case. If you stick to the wizards for creating applications, it is very likely that they will be mostly secure (but that doesn’t mean you shouldn’t still use all of the other tools and practices mentioned).
Secure Development practices
If you are building more advanced functionality then you are unlikely to be able to achieve this using the wizards alone and you are going to be building pages, processes and code manually. There are a number of principles and best practices to follow when doing this which were discussed by Rodrigo in the previously mentioned blog post so we won’t go over it all again. Generally though, if you follow the APEX developer security best practices and manage session state values correctly using bind variable syntax and item protection in both the application and any PL/SQL code on the database, then you will be covered against the biggest threats of SQL injection and CSS attacks.
APEX Advisor
The APEX Advisor is a scanning tool already built in to APEX accessible from the Utilities menu. You can run the advisor against a single page, or across an entire application, checking the ‘Integrity’ of an application and also more recently the Accessibility too. The Advisor checks for errors, use of deprecated attributes, security issues, performance bottlenecks, quality assurance, and other best practices. Each result given contains a link to the component with the issue and a description of the problem found and also, more often than not, an explanation of how to resolve it. Perhaps a description of each possible result could be the topic of a further blog but they are relatively self-explanatory and you can keep running it over and over to check the issue is resolved.
Using SSL
Setting up your instance to use an SSL certificate means that any data transferred between the client in the browser and the server is then encrypted to mitigate against man-in-the-middle attacks. It can be configured to work directly with APEX utilising the Oracle Wallet or alternately be configured on the web server with a reverse proxy to encrypt the traffic between the client and the web server. You can even get free signed SSL certificates from LetsEncrypt now.
You may notice most web sites you visit now will be HTTPS, and Google even ranks HTTPS websites higher than HTTP. HTTPS is the future of the current web.
External Tools
If you are doing everything previously mentioned, then you are a good way towards developing secure applications but there is an external tool available too, which takes things one step further.
ApexSec
At Explorer we utilise ApexSec by Recx to scan and assess the security of any applications and supporting PL/SQL code developed. ApexSec can scan either an export of your application and code or connect directly to the database and is a brilliant tool for assessing the security of an APEX application. It is even utilised by Oracle themselves.
The results are categorised in to Classes and Types in a similar fashion as the APEX Advisor, if you have connected directly to the instance the tool can even take you directly to the component with the issue so that you can apply a fix from within the tool.
Again, we aren’t going to cover how to fix each Class or Type of issue here but ApexSec will give you an explanation of what the problem is and how to fix it. One big advantage it has over the APEX advisor is the ability to mark false positives and attach a reason for marking it as such.
If ApexSec is utilised from Day 1 of a project, and then run regularly, you will find it much easier to manage throughout the development of the application and issues can be fixed or mitigated more easily rather than having to re-write large pieces of functionality at the end. To assist with this process you can even utilise ApexSec as part of a Continuous Integration routine to have it run automatically. We have integrated it with our build server to build the report nightly, we are currently extending this further to automatically assess the results and communicate them to the team when potential issues have been identified.
If you are following or doing everything discussed here then you are likely very much on your way to having a secure web application developed in APEX. As mentioned at the beginning, achieving perfection is an unrealistic goal, especially in an ever evolving and changing security landscape, but doing nothing isn’t an option either.
At Explorer we are currently re-writing our training and there is going to be some much more in-depth material, modules and practice exercises on Security. So, if after reading this blog this is something that would interest you, please get in touch to express an interest. We are planning further presentations and more in-depth guides, blogs and training on the things discussed here as well so please stay tuned.
Author: Paul Jones
Job Title: Oracle APEX Development Consultant
Bio: Paul is a Development Consultant at DSP-Explorer. Paul has a BSc in Computing from the University of Leeds and is now building on considerable experience in development and support using Oracle PL/SQL and Oracle E-Business Suite (EBS). Paul is employing APEX to provide quality, bespoke software solutions both internally and to a range of organisations.