Oracle APEX Security Tutorial

Learn how to harden your Oracle APEX applications! Prevent cross site scripting, SQL injection and more.

Oracle Application Express (APEX) has many security related features that help developers create applications that are guarded from today’s web based threats. But if developers are unaware of these features, how they work and what they guard against, then it is likely they will create applications with at least a few security holes. In this tutorial you will see demos of certain exploits, including Cross Site Scripting and SQL injection, and subsequently learn how to protect against them using the correct feature(s) in APEX or Oracle in general.

Want more? April 10 INTERMEDIATE APEX Training with Expert Tyson Jouglet!

This free training is segmented into several separate lessons:

  1. Overview (1:21)
  2. Is APEX Secure (1:13)
  3. Controlling Access (0:57)
  4. Authentication Schemes (3:08)
  5. Conditions vs Authorization (12:45)
  6. Protect the Ends (12:45)
  7. Propagate the WHERE (3:47)
  8. Session State Protection (8:44) (click on video below)
  9. Other Session State Protection (3:24)
  10. SQL Injection (5:16)
  11. Cross Site Scripting (9:05)

Date: Sep 27, 2012

Want more? April 10 INTERMEDIATE APEX Training with Expert Tyson Jouglet!

NOTE: Some corporate firewalls will not allow videos hosted by YouTube.


Session State Protection

8. Securing Oracle APEX – Session State Protection


>> Dan:  But there’s another means to which you can protect the URL in APEX and it’s called session state protection, built for this very reason. It prevents editing of the item and value portions of the URL which are position 7 and 8 in APEX URL. 




My recommendation when you start to use this feature is to leverage the default. But keep in mind, it must be maintained going forward. What I mean by that is when you enable this feature for your application, you do it in bulk. 


Let’s say you have 100% with 1,000 items. When you enable this feature, pretty much everything will be locked down. Tomorrow you create a new page, add some more items, guess what? They’re not protected. So you have to maintain going forward. 




There is a means to create URLs that leverage this checksum ability programmatically and that’s with APEX util prepare URL. So keep that in mind, if you need to access that, you have a way to do so. 




>> Moderator:  Dan, I’ve got a bunch of questions in the queue and I’ve been a little tardy on getting them to you, so some of them may be a little out of context.


>> Dan:  No worries, by all means.


>> Moderator:  First off, does APEX help with input validation like character whitelist?


>> Dan:  I believe there is a feature for this coming. I’m not too sure. Yeah. There’s a new feature coming in 4.2. Not quite available yet, but we’ll have something very soon. 




>> Moderator:  Excellent. This is a little long, so bear with me on this. I’ll try to read this to you quickly. Where do you put ILOVETOADMIN in the WHERE clause? Could you put the admin group instead?


>> Dan:  Yes. You couldn’t obviously work with Booleans inside of a SQL query so you’d have to maybe make a RATHER function that returns some sort of a flag that you can work with in the SQL world. But absolutely, in fact, it would be much better for you to target it at that level. 


Of course, I can’t stress this enough, really the best way to do this is to use VPD. Using VPD you can setup some policy functions which are centralized at the database tier so you don’t have to propagate the WHERE clauses. You take all this WHERE clauses, you push them into the database and then nobody can get around them. No developer can forget to add them and really no one can get around them. So leverage VPD and you don’t have to worry about it at all. But absolutely you could target by groups, certainly.


>> Moderator:  Right. Back to the report column for the security. I’ve seen the column in the report. Are there any issues with using the security in the report column attributes and set that column security there instead of in the WHERE clause?


>> Dan:  There were two requirements we were implementing. One was to filter the number of rows that the end user saw. That needs to be done via the WHERE clause. 


The second requirement was to lock down that column. Now, you can do some things with VPD that limit data coming through at the column level but I’m not a big fan of that. I would just recommend using the feature here to lock down the column in the app using APEX.




>> Moderator:  Great. Can or could you change the app user ID to admin in the address bar?




>> Dan:  No. That’s going to be a protected item so app user you don’t have to worry about. You just have to worry about the items that you create essentially.




>> Moderator:  Okay. I’m going to turn it back over to you, Dan. We do have some more but we are short on time, so back over to you. Thank you very much. 


>> Dan:  No problem. Where were we? 




I think we’ve just finished locking down the app. Oh no, sorry. We’re digging into session state protection, doing a demo on that. 




This is another way to protect URLs in APEX. This actually is what I have to disable just to show you the hack first. Now we’re going to turn it back on. When you first come to session state protection, look a little weird, it says “Disabled.” You go to set protection and of course you want to enable it. 




Just because you enable it does not mean you’re protected. You have to configure things and the way that you do this in bulk that I was describing before, you come here to set protection and you use the configure option on the right. 




Now you see all these settings. There are two levels where you have page level and then item level. When you look at the page, the default is arguments must have checksum. This is secure. This is a lot better than unsecure, but it’s not the most secure. 


The next level is no arguments allowed which means you cannot even pass parameters in 7 and 8, we’re going to a particular page and here you have a no URL access so you can’t even get to the page using a URL. This level is the most secure. It’s actually so secure I’ve never had a need to use it. At that point to even get to a page one would have to use a particular type of branch which of course we can control programmatically. 




Again, leave the default most of the time and adjust as necessary. At the item level you see unrestricted of course, the least secure. The default here is checksum required session level but less secure is application level. What this means is that the checksum that would be created would be one that is only at the app level. Meaning I could take a URL with the checksum and I could email it to Dave and Dave could put it in his browser and it would work just fine. 


More secure would be user level. What gets included with that checksum is the actual user. So if I try to share that link with Dave, it wouldn’t work. But I could save it as a bookmark in my app and it would work just fine to me tomorrow. 




More secure is session level. That checksum that’s generated is only going to be good for the duration of one session. That’s the default and I recommend you leave it there. 


Of course, there is restricted. This is important to use in certain items such as maybe a user ID which could be hidden. Make sure you lock those down entirely. 




We’ll leave the defaults, enable it for the app, and when we run it now – let’s go back to orders. When I hover over the link and you look at the bottom of my browser, you’ll see the URL. To the right of the branch is 7,4 and now you see &cs=, that’s checksum equals and then 32 numbers and letters that are the checksum essentially locking down what we’re able to do here. Using this checksum if I then try to manipulate the 7 to a 2 and hit “Enter,” we get something completely different. Now we get an error. This is something that you could even write code that cache and then maybe shoot you an email. 




That’s URL protection or protecting position 7 and 8 in the URL. It’s important to remember though that that’s just position 7 and 8. It does not protect me from going to certain pages. If you want to protect certain pages, you do need to use what we already saw before which is the admin schemes. 




If you don’t want somebody going to certain reports – even with this enabled, they’re still able to get to certain pages. For that you need to lock down the page using an authorization scheme.


Copyright 2017

Free Online Registration Required

The tutorial session you want to view requires your registering with us.

It’s fast and easy, and totally FREE.

And best of all, once you are registered, you’ll also have access to all the other 100’s of FREE Video Tutorials we offer!