Oracle APEX Exploitation – Part 3

This is the third in my series of short posts about methods thatc an be used to exploit your Oracle APEX applications. The first two posts concentrated on URL Injection which is relatively easy to protect against, however this third post is going to focus on something that is a bit more difficult to stop, and not quite as obvious an issue. I am going to call it Select List Injection.

Select List Injection

This exploit relies on the application having a select list that has been filtered somehow for the user. For example, a select list may show the list of employees that report to the current user – in reality the list of employees on the base table is a superset of these.

Mechanism of Attack

A simple example is a page which contains a select of employees reporting to the current user and displays a report based on the selected value. The select list only contains the employees visible to the user. We can set up a simple example as follows.
Select List LOV Code:

select ename, empno from emp where mgr=7566 order by ename 

Report Code:

select ename, empno, hiredate, sal from emp where empno=:p5_emp_id 

The method of exploitation here is to use a developer tool to change the HTML for the select list that has been registered. So using the F12 key in most mondern browsers (Chrome, Internet Explorer etc) will pop up the following. We can find the code that has been rendered and modify it inline.

Using the developer tool we can modify the return value of any entry to one not previously in the list. Now when we select that value, we can see the report shows that value. Note – we have session state protection enabled on this page – this attack is not stopped by SSP.
So I will now change that value:

And I can now see values I shouldn’t be able to.

The Implications

This attack allows a user to potentially view information that they shouldn’t be able to. It does rely somewhat on the user knowing a valid value to select, however this generally isn’t too difficult to do – and can often be deduced from other values.

How To Defend Against It

There are only really two ways to defend against this. 1. Use a Fine Grained Access Control (FGAC) mechanism such as VPD or secured views/queries. This is the safest option as security is implemented at the database level. For example, we would change our report code to:

select ename, empno, hiredate, sal from emp where empno=:p5_emp_id and mgr=7566 

Obviously real-world examples are likely to be reasonably more complicated than this – the simiplicity is for demonstration purposes only. 2. We can implement a validation in APEX that checks the value is a valid one for the current user at the point of submission – however we should be aware then that security is being implemented in the application and must be done so in each instance of use, whereas option (1) above will be applied across all usages.

Summary

The thing which we should be most worried about this attack is that it is not stopped by Session State Protection. APEX has to allow changes to the item value in order to allow the user to change their selection. I would like to see APEX internally check that the value hasn’t been modified to one not in the original select list as a standard feature, however at the time of writing this isn’t done. Ultimately, as with any item type, we must make the sweeping assumption that the user may pass any value in it – not just those that they are restricted to. Therefore any report utilizing this kind of functionality must be protected by FGAC.

I think the next topic will cover SQL injection – probably one of the most commonly used attacks on the web. Keep an eye out for it!