Transcript

Protect the Ends

6. Securing Oracle APEX – Protect the Ends

 

>> Dan:  What I recommend when it comes to locking things down with authorization schemes in APEX is that you protect the ends before you protect the means. 

 

[pause]

 

When you’re looking at things like tabs, buttons, really anything with a link in it in APEX that’s just a means to an end. it’s a means of providing navigation. The end itself is what you need to lock down. Things like pages, processes – these are the ends. Lock down the ends first then lock down the means to get to the ends. 

 

So how would we implement this in APEX? 

 

[pause]

 

We’ll start with the easy one. 

 

[pause]

 

When we look at the report – this is the reports main page here and then we have several others after that. You literally have to come in here. Let me just show you real quick – reports is page 26 so there’s no link to it but you can see right now I’m in as ILOVETOSELL and the user has no problem getting to this page. I show even though they don’t see a link to it here they can come up here in the URL, just change this one to 26, hit enter and it get to it, no problem. 

 

So what we really needed to lock down was not the tab or the means to the page but literally the page itself. I’m coming into the page of attributes. I’m going to focus on security and we’re going to apply the authorization scheme at this level here, admin. 

 

[pause]

 

So now if they try the same hack – go back to page one and run the app. 

 

[pause]

 

They don’t see the tab but they try manipulating the URL. 

 

[pause]

 

They’re denied access again. You’ve seen this message now in two places. The message that we’re putting inside of the authorization scheme – this message is displayed in two places. Number one, at the app level. Number two, at the page level. Anything more granular than that you can lock things down. However, it simply prevents them from either rendering or being executed. The error message will no longer be displayed when you get more granular. 

 

Of course, I’ve only locked down one of the reports pages. We then have to go through the rest, 27, 28, and so on. I’ll lock those down as well then the user cannot get to reports. 

 

[pause]

 

The second part was deleting and this unfortunately gets a little bit more complex. 

 

[pause]

 

We go into orders and we take a look at one. 

 

[pause]

 

We don’t see delete. We just see this “Apply Changes” button. 

 

[pause]

 

I’m going to drill into it here and show you here’s the button element and it says on click APEX.submit save. What if we change “Save” to “Delete” and hit “Apply Changes”? 

 

[pause]

 

We’re looking at order 10 Eugene Bradley, action processed, no more order 10. Ah, we need to protect the end itself. Let’s go back to page. 

 

[pause]

 

We’ll drill into the app. What deletes a row? Is it a button press or is it a process? You said process. You guessed right. We go into this process. This is the process that runs on submit. 

 

[pause]

 

We’ll scroll down a bit and you’ll see that it does all three – insert, update, and delete operations. What you have to do to secure this, it’s a little tedious but you need to copy it. You’re going to have to break it up into two. 

 

[pause]

 

We’ll get them right next to each other and we’ll reconfigure them accordingly. This first one I’m going to rename “Insert and Update” and I’m going to remove the delete ability from it. I’m going to make sure that it only fires when a certain button is pressed. I’d like to say, both – there’s quite a few buttons here. I will go with save or create. To handle multiple conditions we’re going to use a PL/SQL expression and refer to request. 

 

[pause]

 

So if save or create is the request guide and one of these two can fire, it knows which mappings to do using these here. 

 

[pause]

 

I don’t need to lock this one down with authorization schemes. The next one I do – here’s the one that does the delete. We’ll uncheck the “Insert and Update” and we’ll leave the condition set to the “Delete” button but here I’m going to apply the security must be an admin. 

 

[pause]

 

Now we have these processes setup a little bit better than before. Let’s try that same hack and see if we can get through. We’re looking at order 9, we come into the button, we change “Save” to “Delete.” 

 

[pause]

 

Notice you do not see a processed success message. Also you still see order number 9. This is important. You must protect the means to get to an end but you must protect the end as well. What I would do is protect the ends first then protect the links that get you there. 

 

[pause]

 

Let’s look at some more requirements. Only admins can edit orders they didn’t place and only admin should see the sales rep column. Okay, sounds easy. 

 

It looks like the way this app is set up by default. All the orders were placed by generic user called DEMO. We’re using different users here, ILOVETOHACK – I’m sorry, ILOVETOADMIN and ILOVETOSELL. ILOVETOHACK can’t get in this app. So let’s go ahead and set this up a little bit differently. 

 

I need to go to the SQL Workshop. We’re going to run a couple of updates. 

 

[pause]

 

You can see this here we’re updating DEMO orders, setting the username to ILOVETOADMIN for order IDs 2, 3, 8, and 9. Just some random IDs and then we’ll do the same, ILOVETOSELL gets everything else essentially. 

 

[pause]

 

Now when we look at the orders, we can see that some were put in by the admin, others were put in by a standard user. What we need to do, only admins can edit orders they didn’t place and only admin should be able to see this particular column. 

 

Let’s deal with the column first. This one’s easy enough. 

 

[pause]

 

We’ll go into a report. Here’s the sales rep. Focus on the authorization. We’ll lock this down to admin. As you can see, these are everywhere. So you can lock down even the most granular components in APEX. 

 

We’ll rerun the page. Excellent. Now the user cannot see that column. But this is where you move over into the next stage where we actually have to protect the data that’s coming through the app and the way that’s typically done is with the WHERE clause. 

 

[pause]

 

>> Moderator:  Pardon me, Dan.

 

>> Dan:  Yes.

 

>> Moderator:  A comment, if you will, in the queue. The comment is the user could also run the OnClick JavaScript in the address bar. I’m not sure I’ve got the pronunciation correct but something about Java script in the address bar. Is that a vulnerability I would say?

 

>> Dan:  Well, I suppose it got to be.

 

>> Moderator:  [09:28 inaudible]

 

>> Dan:  Yeah. You’d have to get yourself into the submission phase to get to where the processes were executed, but there are ways to do that as well if you know enough about APEX and URLs, so there are certainly some vulnerabilities there in URL. Absolutely.

 

[pause]

 

>> Moderator:  Thank you.

 

>> Dan:  Sure. Alright. What we’re going to do is add on the WHERE clause here. 

 

[pause]

 

Let’s say WHERE app_user = “ILOVETOADMIN” – and this is where we need to filter the person and place of the order, order_name. 

 

[pause]

 

Like that. Okay, looks good I think. We’ll apply the change on the page. Perfect. We’re seeing five rows of data, 7, 6, 5, 4. 

 

What we’re not seeing is what we removed or assigned to all of the admin, which was 2, 3, 8, and 9. Easy enough. Perfect. Or is it? 

 

[pause]

 

Let’s go back to the app and take a look at maybe something else a user might notice while using an APEX app. So if go to “Edit this order,” this is one of the ones that ILOVETOSELL is supposed to be able to see. We click on the “Edit” link and we notice up here in the upper right-hand corner – actually, I might have enabled this earlier or it’s enabled by default – what I wanted to show you in fact – let me set something up first. 

 

[pause]

 

We go back to orders. We’re still only seeing what we’re supposed to be seeing. But when we click this URL, a user can easily say some things in this URL such as P29 order ID, P11 branch and if they figure it out what they’re note is that this 7 represents the order ID that they’re supposed to be viewing. 

 

One of the ones they’re not supposed to be viewing, one of the ones that was done by the admin is 2. But if the user manipulates the URL and hits enter then order 2 comes up no problem. 

 

[pause]

 

This is a big, big issue. It’s something known as a URL tampering and you have two basic ways you can protect against it.

 

Copyright SkillBuilders.com 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!

 

×