Oracle APEX Exploitation – Part 2
Following on from my previous post in a series on common exploits in Oracle Application Express, in this post I am going to continue the theme of URL modification, however this time to allow us to execute procedures where we shouldn’t be able to. This issue arises from the fact that we can use the construct BRANCH_TO_PAGE_ACCEPT in an Apex URL to call submit processing. This is explained further below.
URL Parameter Modification
Mechanism of Attack
Take a page which shows a report to all users, however users with a higher level of access are able to click a button which deletes the content of the table. Obviously a very silly example, but it’s enough to show us the principles. The live demo of this can be found here as always.
Our page consists of a report with a simple query:
select ename from emp;
A delete button, DELETE which has an authorisation scheme defined against it to only display when the user is an administrator.
Finally a procedure “Delete Rows” which empties the table. This is set to be conditional based upon the DELETE button being pressed.
begin delete emp; end;
Now to protect my demo application I have modified this slightly to:
begin delete emp; raise_application_error(-20000,'I would have deleted all your data really!'); end;
So now when we run the page we can’t see the delete button (we are not admin) – it appears we can’t do anything. However – recall our URL syntax from my first blog post:
f?p=App:Page:Session:Request:Debug:ClearCache:itemNames:itemValues:PrinterFriendly
What we can do is used a value of BRANCH_TO_PAGE_ACCEPT (with optionally a REQUEST value separated by |) to force the page submit processes to run. I.e.
https://apex.oracle.com/pls/apex/f?p=18281:4:109614502116967:BRANCH_TO_PAGE_ACCEPT|DELETE:NO:::
See that? We have just called the on-submit procedure without actually submitting the page.
The Implications
The implications of this are quite clear – never assume that just because a user isn’t able to submit a page in your application that they can’t run the on-submit processes. In our example, a user without sufficient privileges was able to execute code we didn’t want them to.
How To Defend Against It
Again, this is quite easy to defend against by using page level security. However it is always good practice to protect your processes with authorisation schemes too. If a process can only be run by a subset of users, ensure that restricted is implemented at the process level – don’t rely on application logic to implement security.
Summary
This might seem like a really obvious thing, but I’ve seen countless applications which rely on the fact that a user not being able to see a button to mean they can’t perform a particular action. However as demonstrated above, it simply isn’t sufficient to hide a button. Always assume a user can excute anything in your submit processing section that they are authorised to do so.
I’ll get onto something a bit more interesting next post! 🙂