Part 2 Explanations
Video Activity
This lesson discusses Insecure Object Reference (IDOR). This occurs when a developer exposes a reference to an internal implementation object such as a file, directory or database key. Attackers can then manipulate these objects to access data. The attack vector exploit-ability is very easy. This unit also covers data leakage, specifically authenti...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson discusses Insecure Object Reference (IDOR). This occurs when a developer exposes a reference to an internal implementation object such as a file, directory or database key. Attackers can then manipulate these objects to access data. The attack vector exploit-ability is very easy. This unit also covers data leakage, specifically authentication versus authorization.
Video Transcription
00:04
Hello and welcome to the side. Very secure coding course.
00:08
My name is Sonny Wear, and this is oh US Top 10 for 2013
00:13
a four insecure direct object reference
00:17
Now. First, our definition
00:19
for a four insecure direct object reference a loss past the following definition. A direct object reference occurs when a developer exposes a reference to an internal implementation object
00:36
such as a file directory or data please key and without an access control check or other protection, Attackers can manipulate these references to access
00:49
unauthorized data.
00:52
Now I'm actually pointing out that the term reference here is meant to describe the actual name or the actual database key.
01:03
For example,
01:04
let's go one. If we take a look at a loss chart for this particular type of vulnerability,
01:14
we can see that the attack vector exploit ability is easy. So this is not on Lee easy to exploit.
01:23
But it's also easy to detect, which is good.
01:27
And the impact, of course, can be moderate really depends on how much data is exposed or leaked. Let's take a look at the security weakness definition applications frequently used the actual name or key often object when generating Web pages
01:46
applications don't always verify the user is authorized for the target object.
01:53
This results in an insecure, direct object reference flaw.
01:57
Testers can easily manipulate parameter values to detect such flaws, and code analysis quickly shows
02:06
whether authorization is properly verified. It could, and some scans actually show if the authorization is verified. But there are other times where you really do need
02:19
a manual secure code review done by senior level people on the development team just because
02:28
it's hard for static code analyzers to follow the flow. You could very well have authorization taking place
02:35
up front at the beginning of the program, but not necessarily at the particular method that the Skinner might pick up on. So something to keep in mind. Now let's take a look at some examples of indirect object reference.
02:52
I am pointing out three key areas here files. You're rails and database keys.
02:58
Let's talk about each now files. You can have an insecure, direct object to reference
03:05
when you receive or past the actual name of the file that you're going to retrieve, or that you're going to display
03:13
and
03:14
the same idea can be with you, Earl So if you immediately redirect or relocate a Web page
03:23
to a u R L that's been passed in from the browser from your client side that's received a za parameter. This is also an example of indirect object reference.
03:35
And of course, the reason for this is because
03:38
since that value is being exposed and immediately used, that means it can be manipulated.
03:46
Now let's talk about database keys
03:49
exposing actual database keys, whether its primary keys, whether it's account numbers, it could be foreign key references.
04:00
But any of these keys that are exposed in a Web page itself
04:04
can allow for the manipulation of those keys, which could lead to date a leakage. Now, the reason why it's leading to data leak. It leakages because
04:16
there's a lack of authorization checks in place in your application code, and I'll talk about that in just a moment.
04:23
But let's take a look at this example here. Price
04:27
is a direct object reference on this HTML form. As you can see, even though it's a hidden field,
04:35
the value of price is easily exposed, so we know that anything on the client side can be manipulated by an attacker And so
04:47
this allows for the attacker to change the price to be any price that they want.
04:54
Now. Another type of attack that can occur due to indirect object reference is local and remote. File inclusion. Attack.
05:03
Now this is where you may have the inclusion in your you are a hell of a direct file name that's used to load a Web page,
05:14
and so that parameter
05:16
essentially allows for the passing in of any file name, whether it's local to that machine
05:25
or remote an attack of controlled. And so you see, I haven't pointed out here that the page parameter page equals low dash user dot PHP. That load user PHP file could be changed to be anything that we want.
05:42
And we'll see in the demos how we're able to actually access sensitive configuration files on the Web server that should not be accessible to us. So now let's talk a little bit more about data leakage First, a quick
05:59
reminder as to the difference between authentication versus authorization.
06:03
Authentication, of course, is some sort of verification that you are who you say you are, and that usually comes in the form of username, password and possibly with
06:16
multi factor authentication. Something else, maybe fingerprints or something like that. Authorization, on the other hand, is after you've been authenticated, authorization verifies what you are authorized to do. So these are the rules that provide
06:35
you're allowable actions within an application.
06:39
Now a lack of authorization checks, which we usually abbreviate authorization to just off Z. So off see provides those rules that I mentioned around what a role or what an individual is allowed to do in an application.
06:56
Realized that insecure, direct object reference
07:00
is actually exasperated
07:01
by the fact that authorization checks are not in place inside of your coat.
07:08
Why is this? Well,
07:11
let me explain. So even if
07:14
you have an insecure, direct object reference present on your Web page, if you actually code your authorization checks in the back end,
07:25
then you can mitigate the data leakage.
07:30
For example, if we look at this
07:32
drop down box, we can see that there is an indirect object reference here of exposing the primary keys for these employees numbers. So Tom's number is 24. Involves is 32 etcetera,
07:48
and these numbers correspond to the their actual primary keys in the database.
07:56
Now,
07:58
without any authorization check.
08:01
An attacker can manipulate these values to then be able to view
08:07
other people's information. So even if they're a legitimate user logged in, they could easily change these values to somebody else's because it's exposed on the Web page
08:18
and then without an authorization check, view that other person's information. So the authorization check is actually a way to constrict the sequel
08:31
so that the sequel results from the database are actually
08:37
confined to Onley be viewable
08:39
by the authorized viewer,
08:43
and we're gonna take a look at an example of how to do this inner mitigation section. So from the Certs secure coding standard website, I've picked out one of their rules. This pertains to Java but is certainly applicable to any language
09:01
the rule states
09:03
kinetic allies path names before validating them.
09:07
Basically, Connecticut ization in this particular context refers to fully qualifying path names prior to using them, and so we're going to take a look. Now it's, um, noncompliant code
09:24
to illustrate this particular flaw.
09:28
So in this example, you can see that we are creating a new file instance, and that file instance is trying to confine the file to only be accessible from the image directory. The problem is that
09:46
the argument sub zero is taken in and can captain ated with that image path,
09:54
and there's no further validation being done
09:58
now. The problem here is, of course,
10:01
that the user could pass in the dot, dot, slash attack instead,
10:07
and reference well known files or directories that might be accessible, not locked down on the Web server. And so the main problem here is that the image, plus the contamination of arcs of zero,
10:24
is not being Connecticut sized or fully resolved
10:28
prior to its use. Now, in this compliant version of the code, you see, we still have that image directory. That's his reference as well as the yard subzero. However,
10:41
if you take a look
10:43
at the string canonical path that gets assigned
10:48
were actually performing some kind of validation.
10:52
So we call file, get Connecticut Path, and then we actually do a check to ensure that the paths equal a certain standard. If they do not, we're going to throw in here.
11:05
And so this is a common problem that it occurs in code where we immediately start to use
11:13
ah value because we're not anticipating pity or assuming that it could be used in an illegitimate or nefarious way. So this is something that we need to keep in mind now. The case study comes from Nokia.
11:28
Nokia had an insecure, direct object reference flaw inside of their code in their portal,
11:37
and they exposed as an i. D. These invoice numbers. Apparently these invoice in numbers were exactly the same numbers that were used in their database. And so because of that, it was very easy as a legitimate user to just go to the top,
11:56
change the numbers to some other five digits and actually see the invoice details of a different customer. So two problems here, one they exposed the primary key as a parameter
12:15
and two. They did not have those authorization checks in place
12:20
to verifying that when the results were sent back that they would only be displayed to the appropriate authorized user.
12:28
Now we're gonna move on to the demos portion of our module
Up Next
Instructed By
Similar Content
