Thursday, 16 January 2014

ApexSec Desktop 3.0 Release

We recently released version 3.0 of our unique security analysis product for Oracle Application Express.

Some of the new features include:
  • Ability to assess applications via the Apex application builder using an embedded browser in ApexSec.
  • Enhanced detection routines for SQL Injection and Cross-Site Scripting.
  • New specific checks for Apex 4.2+ features.
  • Major performance improvements allowing even large (30Mb+) applications to be scanned in seconds.
Visit the ApexSec website for a full list of the major changes and a video demonstration of the latest UI and features.




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 http://apexsec.recx.co.uk.

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 build.phonegap.com, 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>
<html>
  <head>
  <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">
  </head>
  <body onload="window.location.href='http://apex.oracle.com/pls/apex/f?p=INSERT_APP_ALIAS_HERE';">
    </body>
</html>

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.

document.addEventListener("deviceready",onDeviceReady,false);

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(){
     alert('Ready')
}

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.