Cloud

O SpecGold OracleBusIntApps7 clr

 Gcloud

 

   Call us now 

  Manchester Office

  +44 (0) 8450 940 998

 

  

 

John's Blog

This is my blog of various topics, from things that I think might be useful to others, to things that I just find interesting personally. If you have any comments or questions on any of my posts then please do ask - any positive contribution is very much welcomed.

The views expressed in this blog and completely my own and do not reflect those of Beyond Systems Ltd. All content is provided for informational purposes only, and you are solely responsible for how you use this on your own or others systems. We accept no liability for any losses or damages caused.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Team Blogs
    Team Blogs Find your favorite team blogs here.
  • Login
    Login Login form

Oracle APEX Application Exploits - Part 3

  • Font size: Larger Smaller
  • Subscribe to this entry
  • Print
Oracle APEX Application Exploits - Part 3

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

Report

 

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.

Developer Console

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:

Change Value

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

King

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!

Last modified on
Tagged in: APEX
in Technical Hits: 845 3 Comments
0

My primary area of interest and expertise is Oracle E-Business Suite, particularly Foundation, Human Resources, Payroll, Time and Labor, Warehouse Management and Inventory. Whilst I prefer to focus on functional aspects I do have a keen interest in technical areas too such as SQL tuning/the optimizer, Application Express (APEX), Unix (particularly Linux) and general development.











  ACE Logo




Cert Logo  
Cert Logo 2

Comments

  • Guest
    Peter Raganitsch Tuesday, 14 November 2017

    The only important finding is that any value coming from the frontend needs to be validated on the backend before using it.

  • John Keymer
    John Keymer Tuesday, 14 November 2017

    Correct - the one and only key point is "always assume the user can pass any value to the APEX application from any item. However just from personal experience at seeing applications developed by various organizations, I think if you took a sample of 1000 applications across a broad spectrum of companies, you'd be surprised at how many don't do that.

  • Guest
    Stephane Labelle Thursday, 16 November 2017

    Thanks, greatly appreciate your post!

Leave your comment

Guest
Guest Saturday, 16 December 2017