Hello and welcome to the side. Very secure coding course.
My name is Sonny Wear, and this is oh US Top 10 for 2013
a four insecure direct object reference
Now. First, our definition
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
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
Now I'm actually pointing out that the term reference here is meant to describe the actual name or the actual database key.
let's go one. If we take a look at a loss chart for this particular type of vulnerability,
we can see that the attack vector exploit ability is easy. So this is not on Lee easy to exploit.
But it's also easy to detect, which is good.
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
applications don't always verify the user is authorized for the target object.
This results in an insecure, direct object reference flaw.
Testers can easily manipulate parameter values to detect such flaws, and code analysis quickly shows
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
a manual secure code review done by senior level people on the development team just because
it's hard for static code analyzers to follow the flow. You could very well have authorization taking place
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.
I am pointing out three key areas here files. You're rails and database keys.
Let's talk about each now files. You can have an insecure, direct object to reference
when you receive or past the actual name of the file that you're going to retrieve, or that you're going to display
the same idea can be with you, Earl So if you immediately redirect or relocate a Web page
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.
And of course, the reason for this is because
since that value is being exposed and immediately used, that means it can be manipulated.
Now let's talk about database keys
exposing actual database keys, whether its primary keys, whether it's account numbers, it could be foreign key references.
But any of these keys that are exposed in a Web page itself
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
there's a lack of authorization checks in place in your application code, and I'll talk about that in just a moment.
But let's take a look at this example here. Price
is a direct object reference on this HTML form. As you can see, even though it's a hidden field,
the value of price is easily exposed, so we know that anything on the client side can be manipulated by an attacker And so
this allows for the attacker to change the price to be any price that they want.
Now. Another type of attack that can occur due to indirect object reference is local and remote. File inclusion. Attack.
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,
and so that parameter
essentially allows for the passing in of any file name, whether it's local to that machine
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.
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
reminder as to the difference between authentication versus authorization.
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
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
you're allowable actions within an application.
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.
Realized that insecure, direct object reference
is actually exasperated
by the fact that authorization checks are not in place inside of your coat.
let me explain. So even if
you have an insecure, direct object reference present on your Web page, if you actually code your authorization checks in the back end,
then you can mitigate the data leakage.
For example, if we look at this
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,
and these numbers correspond to the their actual primary keys in the database.
without any authorization check.
An attacker can manipulate these values to then be able to view
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
and then without an authorization check, view that other person's information. So the authorization check is actually a way to constrict the sequel
so that the sequel results from the database are actually
confined to Onley be viewable
by the authorized viewer,
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
kinetic allies path names before validating them.
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
to illustrate this particular flaw.
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
the argument sub zero is taken in and can captain ated with that image path,
and there's no further validation being done
now. The problem here is, of course,
that the user could pass in the dot, dot, slash attack instead,
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,
is not being Connecticut sized or fully resolved
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,
at the string canonical path that gets assigned
were actually performing some kind of validation.
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.
And so this is a common problem that it occurs in code where we immediately start to use
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.
Nokia had an insecure, direct object reference flaw inside of their code in their portal,
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,
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
and two. They did not have those authorization checks in place
to verifying that when the results were sent back that they would only be displayed to the appropriate authorized user.
Now we're gonna move on to the demos portion of our module