Monday, 6 February 2012

Oracle Apex Application Security - A Year in Review

Introduction

We've been shipping our Oracle Application Express static code analysis product ApexSec for a year now. During the course of the year we've personally analysed over 60 different applications. For a new product and a new company gaining market traction in a niche aspect of security this isn't bad.

The applications we have seen have ranged in size from the small, at sub 10 pages, through to the large at over 200 pages. The average size across all the applications has been 21 pages. As we've done these assessments we've collected anonymous statistics on the volume of findings by type versus the size of the application in terms of pages.

Today we will provide some insight into the state of security in Oracle Application Express developed applications based on our dataset.

What ApexSec Checks for:

The ApexSec security checks can be broadly broken down into five categories:

Access control: A set of Apex specific access control constraints to pages, form, fields and processes.

SQL Injection: An input validation issue which can lead to unauthorised arbitrary database access.

Cross Site Scripting: An input validation issue which can lead to a users session or the application becoming compromised.

Application logic: Variety of different vulnerabilities, some specific to Apex, others generic to the web, that manifest themselves through insecure development practices.

To provide some context in the larger sphere of web application security we're going to focus on two of these areas specifically; SQL Injection and Cross Site Scripting. Both are very common types of web security vulnerability and not specific to Oracle Application Express.

The Big Picture

At the forty thousand foot view the total percentage of applications indiscriminate of size or complexity that we've analysed that are vulnerable to these classes is as follows.

Cross Site Scripting

For Cross Site Scripting, a class of vulnerability which involves being able to inject JavaScript (client side code) into an application either in a reflective or persistent manner:

SQL Injection

For SQL Injection, where an external individual is able to manipulate database queries to either read or write in an unauthorized manner:

Considering our source sample set this is concerning as nearly 50% were less than 10 pages in size yet over 80% were vulnerable to Cross Site Scripting and 40% vulnerable to SQL injection.

The reasons for the high proportion of small applications is due to our cloud service providing a free report for those with 15 pages or less combined with the fact our larger clients have bought copies to run in-house as part of their standard development processes, which we don't get to see any results for.

Another skew on the data is that older applications that have been developed on Apex 3 and lower and then moved onto Apex 4 are not protected by the increased security defaults that exist in Apex 4 and above.

Applications with 20 pages or more

If we then start focussing our attention on larger and more complex applications these percentages quickly increase. The first cut-off point we used were 20 pages or more. This becomes more representative at the low end of applications of at a moderate level of complexity, pages and business logic typically serving a single purpose.

The percentage vulnerable to Cross Site Scripting becomes 100% based on our sample set.

For SQL Injection we see the percentage increases to 73%. This can be explained due to the increase in application logic coupled with the interaction between queries and a variety of different pages.

Looking at the average distinct instances of SQL Injection and Cross Site Scripting per application of those with 20 pages or more that are vulnerable we see the following.

This serves as an indication that these vulnerabilities typically increase not just in their presence but actual prevalence in terms of distinct instances as complexity increases.

Applications with 40 pages or more

When looking at applications with 40 pages or more we're typically into the territory of enterprise applications. Looking at the percentage of total applications that are vulnerable to our two classes of issue we see the following breakdown.

Again 100% for Cross Site Scripting:

An overall increase in the presence of SQL injection.

Again if we look at the average number of instances of these specific vulnerabilities across the vulnerable application we see an increase compared to smaller applications.

So we see that on average each vulnerable application of 40 or more pages has 19 separate instances of SQL Injection and 119 of Cross Site Scripting.

Conclusions

In conclusion it's clear from at least the Oracle Application Express applications we have personally looked at that with an increase in the number of pages and associated business logic comes the greater risk of being vulnerable.

The vulnerabilities found here are the same family of vulnerabilities found in most, if not all other web frameworks and should not be taken as a feature specific to Apex development. Code fixes are usually fairly trivial, a majority of the cost associated with fixing the vulnerabilities is searching for the code which is at fault.

So what are the next steps? If you would to see if your application is vulnerable you can upload your application at no cost to our cloud offering, in return you'll receive a summary report for free with an option to buy the full report if you'd like the technical details. Optionally if your application can not leave your organization you can purchase ApexSec to run locally or alternatively engage us as consultants to analyse your code and work with your developers.