Friday, 6 December 2013

Oracle APEX - Monitoring How Your Changes Affect Your Application's Security.

Every time you alter your Oracle APEX applications, whether it be by modifying some code, changing a setting, or adding something new, you could be diminishing your application's security by introducing new vulnerabilities.

Our ApexSec desktop product is a powerful tool for security analysis of Oracle APEX applications. On its own it is capable of providing you with a detailed report of the security of your APEX application in its current state and advising you how to secure it, and with its integrated APEX builder you can make the necessary changes on the spot. This has proven to be invaluable to individuals and businesses attempting to secure their applications in the run up to go-live.

However, when you encounter vulnerabilities that require you to change the logic or functionality of your application, doing so towards the end of development proves to be more difficult (or at least more time consuming) than doing so throughout the development process, and can lead to a major overhaul of your application's design. Being able to keep track of your application's security throughout the entire development process is the key to achieving both security and efficiency.

ApexSec can be run effectively using a Continuous Integration product like Hudson. You can set up a Hudson build to run ApexSec periodically, this could be every hour, every day or every week. The time-frame is up to you. This means that rather than running ApexSec against your applications manually when you see fit, Hudson will do it automatically, and it will paint a very clear picture of how your changes have altered the security of your application using a graph and report.

Example - For a full guide to setting up ApexSec with Hudson click here.

Using our BigBagBlog application we can illustrate how this gives you the ability to strictly monitor how every change, or a collection of changes, affect the security of your application.

Above is the job dashboard screen in Hudson after first running builds using ApexSec. You can see a graph showing the total number of items found (count). You can also see the total number of 'Passed' (secure), 'Failed' (insecure) and 'Skipped' (false positive) items which can be seen in more detail by clicking on 'Latest Test Results'. This means that if you schedule Hudson to run periodically, for example every hour, it will begin to give you feedback regarding the changes to your applications security during that time period.

Now, if we introduce some vulnerabilities in the time between builds you will see something similar to this:

Straight away you can see an increase in the number of failed (insecure) items from the previous Hudson build. This is because ApexSec has detected new vulnerabilities in your application. This means you have done something to create these new vulnerabilities. It's important to bear in mind the time frame can be easily altered by changing the settings of your Hudson build.

From this point there are a few things you can do. You can review the output generated by ApexSec using Hudson by clicking on 'Latest Test Results'. You can also launch ApexSec and open the project file for your application. This will give you full details of the new vulnerabilities and our recommendations for resolving them. Don't forget, all Hudson is doing is continuously running ApexSec against your application, it still creates and updates a standard ApexSec project file, it is just updated more regularly and therefore is a more accurate representation of the current security stance of your application.

- Open your project file with ApexSec for a more detailed description of your new vulnerabilities, including recommendations to resolve them.

Now that you have now been made aware of these new vulnerabilities in your APEX application, you can follow the recommendations provided by ApexSec to resolve these problems as they occur, which is a lot less hassle than trying to do so towards the end of development.

With ApexSec scanning your application periodically using Hudson you end up with a real-time representation of the security of your application and also a plethora of information regarding it's security throughout the entire development process. 

For a complete guide on continuous integration with ApexSec, visit our website

Or contact us for more information regarding our products and services.

Monday, 25 November 2013

Oracle APEX - Native Mobile Applications With Access to OS Functionality

A lot of you will have at some point created a mobile application using Oracle APEX. Like all APEX development it is intuitive and easy to produce working results. However, the applications sometimes fall short in terms of functionality compared to native mobile applications, which are able to easily access the phone's native operating system functionality.

To install your APEX applications natively on your mobile and gain access to your phone's features you can use PhoneGap, an application container technology that allows you to create natively-installed applications for mobile devices using HTML, CSS, and JavaScript. Its core engine is also 100% open source, under the Apache Cordova project.

PhoneGap provides an application programming interface (API) that enables you to access native operating system functionality using JavaScript. You build your application logic using JavaScript, and then its API handles communication with the native operating system. In short, it allows you to install your APEX application on your mobile and access functionality such as the camera, the contact book, the accelerometer and a range of other features which are listed here.

In order for an APEX application to be able to access these features there a few steps you must follow. By far the easiest method is to use, a cloud based service that allows you to quickly build mobile applications and easily compile them without SDKs, compilers or hardware.

Archive an Index.html file to a zip containing the following code:

<!DOCTYPE html>
  <title>APEX DEMO</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no;" />
<meta charset="utf-8">
  <body onload="window.location.href='';">

After signing up for an account or logging in with your GitHub account you can then upload this file and it will build your application, injecting the necessary files in the process.

You then choose which platform you would like, we chose android. The app that has been created does nothing apart from open your APEX application in a "chrome-less" web browser window and bridge the gap between your phone's features and the web application you created in APEX.

Download the app in the relevant format (ie .apk) and then use your preferred software to unzip this file in order to retrieve its contents. Specifically you are looking for a file named "phonegap.js".  You will need to include this file in your APEX application.  Click here to see our guide to including JavaScript files in APEX.

We referenced the file in the JavaScript | File URLs field of our application's page template:

Before you can begin using PhoneGap to access features on your phone you must add an event listener for the "deviceready" event that fires when PhoneGap is ready. This is to avoid your application calling a PhoneGap function before the JavaScript has loaded. See the documentation for more information.


When PhoneGap is finished initialising, it calls the "onDeviceReady" function. This could be called anything you like and do anything you like. It is simply a callback function to handle the event, but it needs to be defined somewhere on your page or application i.e:

function onDeviceReady(){

This will pop an alert up to let you know that it has initialised and you are now ready to safely make calls to PhoneGap function.

There is a lot you can do with PhoneGap and they are constantly updating their features and support for various devices. If you want to know what to do now that you have handled the "deviceready" event, you can browse through their API documentation which contains some very clear instructions for each feature.

Oracle Apex - Including JavaScript on Multiple Pages

We recently came across the need to include some JavaScript in every page of an APEX application. We were implementing a JQuery accordion style menu as seen here.

After the menu was in place, we decided it would be good to have the relevant panel remain open when navigating to a page in the application. One method this can be achieved is with some JavaScript like such:

                                                                   Click here for the JavaScript code used above.

The issue here is, despite the many uses of the global page (zero), you cannot use it to have some JavaScript code on every page.

There are a few solutions. One is to save the necessary JavaScript as a “.js” file on your computer and then upload it directly to your application workspace. This is done by navigating to shared components > static files and then clicking upload. Now you can either navigate to Application properties > User Interface or to your page template, and under JavaScript you can link your file as “#WORKSPACE_IMAGES#YOURFILE.js”.

Using the page template is recommended as you have more control over where the JavaScript will be present in your application.

Alternatively, as of Apex 4.2.2 you can specify which pages have the JavaScript file present on them manually rather than it being present on every page in your application. To do this, on the page(s) you want the JavaScript file included, go to Edit Page Attributes and under JavaScript there is a "File URLs" field. Link your file here with the relevant URL.

The next step is to check that the JavaScript is present in your application. If you have a browser with a built in console, or if you have software like firebug, you can open the console on a page in your application and go to resources > (f) > Scripts > wwv_flow_file_mgr.get_file and this should now display the JavaScript you previously uploaded.

 If it does not show your JavaScript, try re-uploading with a different file name and changing the link to match (#workspace_images#yourfile.js)

Thursday, 18 July 2013

Oracle APEX - JQuery UI XSS Bug

JQuery UI is a brilliant library included in APEX that can help developers with both the functionality and the aesthetics of their applications. However, it is not without its bugs. There is a known bug in JQuery UI (#6016) that causes a cross site scripting vulnerability in applications that include modal dialogs with dynamic titles.

Here is a simple example of a Cross Site Scripting (XSS) attack that exploits this bug in the code from our previous blog post:

Although this bug has been fixed in JQuery UI v.1.8.4, APEX 4.2.2 ships with version 1.8.22, so in terms of developing secure applications with APEX, this is still an issue that must be addressed in order to ensure your applications are secure.

The issue is that the Jquery dialog box does not HTML escape the data before rendering it in the title, therefore this must be done manually by the developer. To fix the issue you can add the following line to your JavaScript function:

                                                         title= $('<div/>').text(title).html().replace('"','&quot;');

The text() function in JQuery HTML escapes anything within it apart from single and double quotes, so for added safety we included double quotes by adding “.html().replace('"','&quot;')”

This and other security issues are regularly found in our code reviews for our high security installs.

Oracle APEX - XSS in JavaScript column link URL

The more security conscious of you may have noticed, or may be interested to know, that there is a cross site scripting vulnerability in the column link URL when using JavaScript. This is regularly flagged in our ApexSec security scanner. In this post we will use an application with JQuery's modal dialog to illustrate this common vulnerability and its simple solution. - Check out our previous post on how to have page access protection for pages inside modal windows.

This type of problem has been mitigated in APEX 4.2.2, if the URL field of your link column starts with 'javascript:', APEX will JavaScript escape the template variables before replacing them within the JavaScript block. This is a security upgrade intended to remove the risk of this type of Cross Site Scripting (XSS) attack.

This vulnerability is with the second parameter of the modal window call (in this case the #ENAME# template variable). Modal dialogs are a common feature within any application and they allow you to give the dialog a dynamic title to enhance the User Experience (UX).

In our example, the title of the modal window opened when the edit link in the report is clicked is defined by the 'ENAME' column. So if you click to edit the employee named 'blake' then the title of the window is 'blake'. Here you can see the difference between the JavaScript in the previous blog post and the Javascript necessary to have a dynamic title in the modal window:

       Comparison of the JavaScript used in our previous blog post and the JavaScript required for a dynamic title.

We have added a second parameter called 'title' to our mymodal function. The title is no longer being defined literally as “Some title” and is now defined by the parameter variable 'title'.

Now navigate to the URL field in the link column section of the report attributes and use the template variable #ENAME# to pass the value from the ENAME column into the title parameter of the 'mymodal' function..

Whenever an edit link is clicked, the title of the modal window is set to the value of the “ENAME” column for that row in the report.

The vulnerability occurs because the template variable is only HTML escaped. This leads to an injection attack within this function call. Because the template variable occurs within a JavaScript block you can pass any text you like into the title, including JavaScript and you are therefore vulnerable to a XSS attack;

If you are using a version of APEX less than 4.2.2, your first course of action should be to ensure that the URL field for your link column is not passing a potentially malicious title to the modal window function. Our method of doing this is to create a new column in the query for your report with the following PL/SQL:

This JavaScript escapes the values in the column “ENAME” and then names this new column “ENAME_JS”. You can go ahead and make this column "HIDDEN" in order to maintain a user friendly report. Now in the URL field for the link column your second parameter should be changed from “ENAME” to “ENAME_JS”. This ensures the values being passed into your modal window function are JavaScript escaped.

In our next post we will discuss a known bug in the JQuery version that is shipped with APEX 4.2.2, as it causes another cross site scripting vulnerability in this example application that also must be fixed in order to fully erradicate the threat of XSS.

Click here to download the application used in this example.

Wednesday, 17 July 2013

Oracle APEX - URL Checksums and JQuery Modal Dialogs

The Problem

We, like many others have stumbled upon the issue of pages not loading inside a Jquery dialog when the page access protection is set to “Arguments must have checksum”. This is an essential security feature in APEX that prevents the manipulation of the URL in APEX pages. You will see the following error when the dialog is opened:

In our example, both the edit link in the report and the Create button outside the report must be able to successfully open the DML form inside the modal window. The problem being that the page fails to load due to the checksum not being correctly generated.

We used the following JavaScript to open the JQuery dialog:

                                         With “url” being defined in the URL field of our report's link column settings. 

We changed the target of the link column in the report from “A page in this application” to “URL” and then defined the URL as:

The issue here is that there is no checksum being generated for this link, so therefore the destination page (page 3) fails to load inside the modal window because the page access protection is set to require checksum.

The Solution

Our solution is to create a hidden column in the report, and use the “Apex_util.prepare_url” function to populate this column with the relevant URL and checksum for each entry in the report. We'll then use the template variable for that column to pass the URL into the JavaScript function call for the JQuery modal dialog.

To do this, navigate to the report region, Go to the "Region Definition" tab and in "Region Source" you should add the line:

This adds the column “LINK_URL” to the report and populates it with the URL for the edit form page. This time the checksum will be generated. We must now return to the page and make this column's display type “HIDDEN”. - When adding or removing a column from a report, you may have to log out and log back into your application for the changes to take effect.

The next step is to insert the template variable (#LINK_URL#) for the hidden column into the JavaScript function call. Navigate back into the report, drill down into report attributes > column link settings and change the “URL” field to be:

Now when the edit link is clicked in the report, the modal window will open and because the checksums are being correctly generated, the page will be displayed.

There is also a problem with the “Create” button used to add entries to the report. The template variable #LINK_URL# cannot be used as it exists in the report row and not in the page.

Our solution is to create a page item on the page and set its display type as “HIDDEN” (we named this P2_HIDDEN).

We then create a dynamic action which will contain two “true” actions, both of which are to be executed when the “Create” button is clicked.

The first of these actions will be to execute some PL/SQL code to populate this new hidden item “P2_HIDDEN” with the URL to open a blank DML form. We still need to generate a checksum because of the clear cache parameter. So the first “true” action should be:

              PL/SQL Code: :P2_HIDDEN := Apex_util.prepare_url('f?p=&APP_ID.:3:&SESSION.::&DEBUG.:3:');

As you can see, one difference here is that we no longer need to include “empno” as this page is for creating a new entry, not editing a current one. Because of this we have also included '3' in the clear cache portion of the URL. We also set “Page items to return” as the hidden page item, in this case it would be “P2_HIDDEN”. This ensures the new value is returned into the page.

Now that the new hidden item has been populated with the URL we must create a second “true” action to execute the JavaScript code necessary to pass the value of “P3_HIDDEN” into the Javascript function and successfully open the URL in the modal dialog window. This true action should be:

                   JavaScript Code: mymodal($v('P2_HIDDEN'))

The edit link in the report and the create button will now function as intended. The modal dialog window will open with the correct page and the checksum will have been generated in the URL allowing you to maintain the page access protection and avoid URL manipulation.

Click here to download the application used in this example.

Tuesday, 2 July 2013

Interviewing APEX developers - Are your candidates security aware?

During our regular search for Oracle APEX security things, we stumbled across a blog post called: "Oracle Application Express (APEX) Interview Questions". Selecting the right candidates to fulfil your development requirement is always tricky, and the whole process of interviewing is a difficult thing to get right. There's a interesting book on how Google handle selection of candidates, although more recently Google have admitted that such techniques may be a waste of time.

We've interviewed candidates for a range of positions throughout our careers, sometimes these are just question based, and some had a technical assessment element. Best of all were the general discussions over a beer. So we like the ethos of the APEX interview questions blog post, as a guide to what should be talked over, but we think the security section could use a little refinement. Below we've listed fourteen questions that an interviewer could ask their candidates to judge their overall security awareness with Oracle APEX applications. The skill in assessing the candidate is perhaps not their complete and accurate responses to the questions, but how they handle difficult problems and their thought processes when problem solving.

Interview questions on Oracle APEX security:
  1. Discuss why allowing a user to set an item's value can, in some cases, be dangerous.
  2. Describe three ways an APEX item value can be set by a user.
  3. Explain how the different protection settings can be used to protect item values from being set by the user.
  4. What class of vulnerability can be introduced by using substitution variables in SQL with APEX applications?
  5. Describe another way such security risks can be present in an APEX application.
  6. What's the difference between a Standard Report Column and one that is set to Display as Text (escape special characters)?
  7. What type of vulnerability can result from using the former type?
  8. Why would you use a Standard Report Column rather than the other type?
  9. How can you ensure that the data displayed in a Standard Report Column is safe?
  10. Describe another way that this vulnerability class can be introduced into your APEX applications.
  11. What's the difference between authentication and authorisation?
  12. Describe several policies that would normally be enforced for authentication?
  13. If you have a report in your APEX application that should only be accessible to certain users, how can you protect it?
  14. Which are the four things in APEX that can be protected with authorisation schemes?
Depending on the role we wouldn't expect every candidate to answer all of these questions. But it could prove useful to explore some of them to ensure that security awareness is part of the selection criteria when interviewing for APEX developers.

If you'd like to learn more about Oracle APEX security, check out our Hands-On Oracle Application Express Security eBook. Our US partners over at SkillBuilders also offer APEX specific security training. For answers to the above questions, contact us and we'll send over details.

Wednesday, 26 June 2013

SQL Injection demonstrations from KScope13

The videos from our presentation on SQL Injection vulnerabilities that can arise in APEX applications can now be streamed online:

We're always keen to here your feedback and answer your security questions so please get in touch.

Wednesday, 22 May 2013

Hands-On Oracle Application Express Security - now available in a wide range of eBook formats

Our new ebook about APEX security "Hands-On Oracle Application Express Security: Building Secure APEX Applications" is now available from a wide range of online stores:
Our book takes a lead-by-example approach to demonstrate attacks against security vulnerabilities in APEX applications. We show the reader how simple mistakes can open up risks in APEX applications, and then guide them through using simple "hacker" techniques to exploit the issues. The reader is then shown the correct way to secure their application so such exploitation is not possible. The book also covers Access Control, Cross-Site Scripting, SQL Injection and the APEX Item Protection mechanisms.

Many of the examples in the book have been stripped down to be simple, to show the core problems and solutions. We also list some more complex examples taken from real-world applications (suitably anonymised!) to ground the security risks. Explanations of why the fixes are relevant and the impact of attacks are also included.

We hope our examples and explanations help APEX developers create secure applications.

Wednesday, 27 February 2013

Recx add Oracle APEX detection to Tenable Nessus

Recx have authored a selection of plugins for Tenable's automated vulnerability analysis product Nessus. These facilitate the detection of Oracle APEX instances when networks are scanned by Nessus. The plugins can locate and analyse APEX web technology stacks to assist penetration testers, ethical hackers and network auditors in the identification of vulnerable versions of Oracle APEX on corporate networks.

In total Recx submitted thirteen plugins to Tenable all of which have been approved and are now including in their update feed for the Nessus Vulnerability Scanner. This allows Nessus to detect:
  • The presence of Oracle APEX on any web servers discovered during a network audit.
  • Determine the version of Oracle APEX in use.
  • If the APEX application builder interface is available.
  • Specific publicly disclosed vulnerabilities in the APEX instance.
Several vulnerabilities in the core of APEX have been released publicly and have Common Vulnerability and Exposure (CVE) references; the Recx plugins for Nessus can identifiy if these issues affect the discovered APEX instance:
  • CVE-2008-4005 - "Unspecified vulnerability in the Oracle Application Express component in Oracle Database allows remote authenticated users to affect confidentiality, integrity, and availability via unknown vectors."
  • CVE-2009-0981 - "Unspecified vulnerability in the Application Express component in Oracle Database allows remote authenticated users to affect confidentiality, related to APEX."
  • CVE-2009-1993 - "Unspecified vulnerability in the Application Express component in Oracle Database 3.0.1 allows remote authenticated users to affect confidentiality and integrity, related to FLOWS_030000.WWV_EXECUTE_IMMEDIATE."
  • CVE-2010-0076 - "Unspecified vulnerability in the Application Express Application Builder component in Oracle Database allows remote authenticated users to affect confidentiality, integrity, and availability via unknown vectors."
  • CVE-2010-0892 - "Unspecified vulnerability in the Application Express component in Oracle Database Server allows remote attackers to affect integrity via unknown vectors."
  • CVE-2011-3525 - "Unspecified vulnerability in the Application Express component in Oracle Database Server 3.2 and 4.0 allows remote authenticated users to affect confidentiality, integrity, and availability, related to APEX developer user."
  • CVE-2012-1708 - "Unspecified vulnerability in the Application Express component in Oracle Database Server 4.0 and 4.1 allows remote attackers to affect integrity via unknown vectors."
These latter three issues were discovered and responsibly disclosed by Recx during the course of our ongoing vulnerability research into the Oracle APEX platform. These plugins are enabled by default:

Maintaining a current version of Oracle APEX is one part of the story to ensuring your environment is protected against cyber attacks. In addition to keeping the framework up-to-date, it's critical to ensure that the deployed APEX applications are secured from web-level attacks such as SQL Injection and Cross-Site Scripting. Our ApexSec product can perform automated code level inspection of your in-house APEX applications, allowing the identification of vulnerabilities and the rapid mitigation of exposures.

We thank everyone at Tenable for accepting and integrating our plugins into their world leading product. We hope this helps our customers and the wider community maintain a secure operating environment in which to host their APEX applications.

Tuesday, 26 February 2013

Hands-on Oracle APEX Security

We have noticed that even developers with the best of intentions can still end up with vulnerable APEX applications. That's why we're in the final stages of publishing a book that is going to cover the various classes of security risk we have experienced when securing high security APEX installations over the years.

All the examples are taken from real-world APEX applications, just sanitised and distilled to demonstrate particular areas of vulnerability. The book gives examples of vulnerable code and shows the correct way to fix your applications. We've submitted the technical content to the publishers and the edit is underway.

The structure so far breaks down into the four main areas of risk:
  • Access Control - applying authentication and authorisation schemes, common pitfalls.
  • Cross-Site Scripting - attacks and defences, encoding functions.
  • SQL Injection - query syntax modification, impact of attacks, subtle differences between vulnerable and non-vulnerable PL/SQL code.
  • Item Protection - classification of items and the protection each type required.
Learning through example is a great way to experiment with APEX security and equips developers with some of the tools and techniques used by attackers. By showing step-by-step how data can be accessed with SQL Injection or how users can be attacked with Cross-Site Scripting, developers will be made aware of attack techniques and understand how the defensive mechanisms of APEX can be used to protect their applications.

Most existing texts on APEX security are consigned to just a chapter within existing programming books or simplified to such an extent as to give a false sense of security. This book gets into the mindset of hackers and deep into the APEX framework to tackle the difficult world of security head-on.

We're proud to be working on this eBook with Wiley who publish the wonderful Web Application Hacker's Handbook, a must read for any web technology developer.

We're hoping to announce the release of our Hands-on Oracle APEX Security eBook in the coming months; watch this space!