Oracle APEX Exploitation – Part 1

I decided to write a short series of posts detailing some different mechanisms that a malicious user may use to “attack” an application written in Oracle Application Express (Apex) – note – “Attack” is used loosely here in that it is more of “making the application perform in a way it was not intended”. These posts are not intended to be instructional, more they are intended to assist the developer in ensuring their applications are written to a standard which protects against such attacks. It should be noted from the outset that none of the techniques illustrated infer there is a security issue with Apex – Apex is secure for all intents and purposes – any security vulnerabilities are 99%+ of the time due to the developer not implementing appropriate defences. Some of them are quite obvious, however some may not be so. I won’t be using any fancy tools – just a browser with developer plugins.
I’ll try to explain a problem under a number of headings.

• The mechanism of the attack
• The implications
• How to defend against it

It of course goes without saying that all liability is relinquished – anything you do to your own (or other’s) applications is entirely at your own risk.

I am using a sandpit application on apex.oracle.com to demonstrate, which can be accessed here.
So with that said, the first thing I’d like to show is by far the most simple – URL Parameter Modification. I’ll then work through more complex and intricate attacks in subsequent posts.

URL Parameter Modification

Mechanism of Attack

This type of attack involves a user intentionally modifying values in the Apex URL to give undesired results on a page. So first, we need to understand the format of the Apex URL. That can be found in the Oracle Documentation here, and is as follows:

f?p=App:Page:Session:Request:Debug:ClearCache:itemNames:itemValues:PrinterFriendly 

So let’s assume we have a simple page which contains some basic data from the emp table, restricted to just those employees reporting to JONES. Upon clicking the employee number, we link off to another page, page 3, which has an item P3_EMPNO that is set with the empno of the employee we clicked. The report on that page shows the salary for the selected employee.

> Click through to >

When we click on that link though, look at the URL that is generated:

https://apex.oracle.com/pls/apex/f?p=18281:EMPLOYEE_SALARY:4107183592951::NO:RP:P3_EMPNO:7902 

Your session ID will be different to mine of course. However – see that last bit: P3_EMPNO:7902. That is setting the value of P3_EMPNO to 7902 when the page is loaded. Say I know the president’s employee number – a simple modification to the URL – f?p=18281:EMPLOYEE_SALARY:4107183592951::NO:RP:P3_EMPNO:7839 – allow’s me to see his salary instead!

So I can modify the value to anything I wish – and see that employee’s details, despite this not being intended functionality.

The Implications

Whilst the first report restricts me to only a specific set of employees, by simply modifying values in the URL, I can see other values on the linked page. I can modify any value on the page using this method, whether it is displayed or not, unless the appropriate controls are in place.

How To Defend Against It

This is generally (there are some exceptions – see later posts) quite easy to protect against. We simply need to enable session state protection at the page level (it is disabled by default).

There are several options – two should be self explanatory, so I’ll only explain the third – “Require Checksum”. What this does is prevent modification to values in the URL by calculating a hash value (checksum) on the values. If a value is modified then the checksum is no longer valid, and an error is shown. If we create our hidden item we choose Value Protected = Yes with session state protection enabled, when we click the link, we can see that a different URL is generated:

https://apex.oracle.com/pls/apex/f?p=18281:EMPLOYEE_SALARY:4107183592951::NO:RP:P3_EMPNO:7788&cs=12VoPH1vlC3fwWdMVEZ3aT_0zuiWDzz7pLVQa6I-TvcLHqh8qSp2dVfb1E02_jlgQ7PiNSIHxRyWw6vfsjaRmhw 

So now if I try to modify the value of P3_EMPNO, the checksum is invalidated, and Apex will complain:

The other method of defence, and this should be considered even if using the above, is to use Fine Grained Access Control (FGAC) such as VPD or views. This ensures security at the database level, which is always a preferred solution. In fact I would probably go as far as to say you should always use some form of database level FGAC if you wish to restrict a user to a particular subset of data.

Note that this is only one of a number of URL modification attacks – I will cover some more in future posts. The important point to take from this is that you should always assume that any item in an Apex application could be any value within a session. If that is likely to cause your application to break or behave unpredictably, it’s quite possible you have a security issue.

Summary

This was of course a very simple example, yet one that is surprisingly effective. Many people choose not to enable session state protection because it prevents them setting values with JavaScript etc (JavaScript runs client side and can be modified). That should be no excuse though – as you ca see it’s very easy to take advantage of such instances.
Check back in a few weeks when I’ll be posting some more advanced topics.