Whenever you are developing a web based application, there are many security concerns that need to be considered. When developing using Oracle Apex, there are a number of in-built security features available to enhance Access Control and Session State Protection, and to also prevent SQL Injection and Cross Site Scripting. This series of blogs will outline the security issues faced by any web based application developer and then detail how Apex can provide a solution.
If components of an application are poorly configured or not fully configured, this can lead to security vulnerabilities exploitable by hackers. Below are some common access control issues that need to be considered when developing a web-based application.
If the browser cache is enabled within an application, the browser is able to save the contents of a page to disk. If a user clicks the back button, for example, the page would be loaded from this cache rather than re-downloaded. Unauthorised users navigating through the browser cache may be able to access this information.
For any pages in your application that hold sensitive data, the Browser Cache should be disabled. If the whole application holds sensitive data, the Browser Cache can be turned off on an application level.
Auto Complete enables a browser to populate form fields automatically based on previously entered data. Any malicious user accessing an application with the same browser may be able to access this stored user input..
Auto Complete can be easily turned off in Apex for individual items on a page. This should be done for any sensitive items in your application such as username and password fields.
Any pages in an application that are accessible by un-authenticated users are more vulnerable to attack. Any database content on these pages is accessible without logging in to the application.
It is recommended that only the log-in page of your application is public and all other pages have authentication enabled. This can be easily achieved in Apex by simply altering security settings of each page. If other public pages are required then ensure that the database content on the page is minimal to reduce the risk of attacks.
In Apex, On-demand application processes are defined within an application’s shared components and can be invoked using a URL or a JavaScript call. Malicious users may attempt to call these processes out of context and perform actions against the database that they would not have been able to call programmatically.
All application on-demand processes and AJAX callbacks should have conditions defined so that they can only be called within the context intended by the developer.
Applications are often deployed live in development mode. This would allow the application to be altered in the production environment by anyone who gains access to a developer account.
Apex applications can be easily deployed in either run and edit mode or run only. Any live applications should be deployed as Run Application Only in the application build status options.
Some application pages can be embedded into HTML frames – often when accessed as a Modal Popup. These embedded frames are vulnerable to clickjacking attacks, allowing malicious users to add transparent layers to the frame and hijack a user’s mouse clicks or keystrokes. These can then be directed to another application.
Apex allows developers to easily block frames from being used by an application. If frames are required as part of the application design then there is an option to allow frames from within the application but not from any external source.
Apex includes a built in file browse item that can be added to a page to allow users to upload their own files. However, all these files are stored in the APEX_APPLICATION_FILES table and are not protected from unauthenticated users. If a user is able to invoke the download_my_file procedure, they can obtain any file stored in the table, whether this was intended by the developer or not.
Custom file storage solutions should be implemented to stop unauthorised attempts to download files using the generic file storage table and procedure.
Applications often include the functionality to restrict a user’s access to pages and items based on their privilege level within the application. In Apex there are a number of ways to achieve this, often by assigning conditions to page items, buttons and processes. However, vulnerabilities can occur when conditions are not consistently applied.
For example, a delete button may call a delete process when clicked. This button can be hidden from a user based on their role, but if the process itself isn’t also conditional then it could be invoked manually by a malicious user.
Ensure that conditions are applied against all items, buttons and processes that control application functionality, even if they cannot be accessed from the screen.
As you can see, there are a number of security vulnerabilities to consider when developing a web-based application, but Apex comes with a wide range of in built tools to allow you to fix them. Be sure to check my next blog where I will be discussing session state protection and more of the application security features available in Apex.
Author: Craig Sykes
Job Title: Senior Oracle Development Consultant
Bio: Craig is a Senior Development Consultant at DSP-Explorer. Craig has an MSc in Computing Science and is an experienced software engineer, utilising development tools such as PL/SQL and APEX to provide bespoke ERP software to both UK and international businesses. Craig has experience developing solutions to connect Oracle systems to a wide range of existing external applications within business environments.