Hello and welcome to the side. Very secure coding course. My name is Sonny. Where and this is AWAS top 10 for 2013
a four insecure direct object reference. Mitigations, countermeasures and defenses. So, first, an overview of the defense's. We're going to look at properly inserting authorization checks into different areas of our Web application,
including the sequel statements for retrieving data sets,
files or directories and then, of course, application content, ensuring that it's viewable by only authorized users.
We'll also take a look at how we can use access controls in order to accomplish authorization checks.
So we'll speak about ankles and are back in other off ze codes that could be used
now. The second defense that we're going to look at is token ization. Now a token is actually some sort of reference number that is inert out of context, meaning that it's harmless or cannot be used in any valuable way if taken out of context.
Now, for situations where we don't have authentication and authorization available, or maybe it's not appropriate, we can certainly use token ization to help us mitigate against insecure, direct altitude reference.
And then finally, the combination of the two really make the best of both worlds, where we have some sort of authentication check as well as three use of tokens. And this can help us to mitigate both insecure direct object reference as well as data leakage.
So first, let's take a look at authorization checks in the database.
Now, this revolves around the sequel construction that we do when we make our sequel statements, we need to make sure that we always include authorization checks. Now the code that you see on this slide is Kobol sequel code, and if you take a look
prior to the highlighted line,
you can see that we're just doing a select statement. We're selecting the product code
now. Normally, we would just have in our sequel statement inside of the Wear Klaus, where the product code is equal to whatever product code maybe received from a previous call.
This, however, can lead to insecure direct object reference. And so the addition of the and Klaus inside of the where Klaus is, how we can restrict
the viewing off this data set or the results set
to just be are authorized user now in regards to adding authorization checks around files or directories. We spoke earlier about finanical izing or resolving fully paths or directories to files
prior to doing any kind of validation.
In addition to that, we can add ankles or access control. Lis.
This is really good, because what it does is insures that not on Lee
Are we validating against a fully resolved path,
but also that we are doing our proper authorization check to ensure that whatever that operation is is being performed by the authorized user.
Now the sample C c++ code that I have below
actually does a check against the full path First. Resolving that
and then does the validation check, and you can see that in the if statement there isn't else. So if the expected path is not received, there were going to throw an exception.
Now authorization checks in regards to application content. So this is where you can actually check the role of a user or maybe the user's account privileges. Make sure you always do that on the server side
in this C sharp code. Example below, you can see that there's a check off the user's rolled
prior to the replacement of the location variable.
So in the code you see, there's an if statement if the user is a batch admin than you can perform this block. Otherwise throwing error that states unauthorized user
Now token ization is yet another defense that we can use. This is where you're going to map a token in place of that direct object. Now the token. The idea is that it is inert if taken out of context, meaning
it's harmless or it's of no value to an attacker
if it's not used within the context off the mapping.
to our initial example that we have with Tom, Bob and Alice and their employees numbers, you can see that their values now our token ized, it's some sort of
other reference number. Now there's different ways that you can do token ization.
If you look on the right hand side, you can see the rial primary keys for Tom, Bob and Alice.
Those have been replaced by some sort of generated token.
Now, a generated token can be done through a special service, a proprietary a p I. But it is something that that is generated at the time when it is needed to be used. And so you can see I've written some sample code here.
This is just a code snippet to give you an idea of how a token ization service might be used.
So the first thing that you would do is you would query your database to get the actual primary keys first.
Then you would call your token ization route routine to generate a token that corresponds to your primary key. Now there are token vaults involved in order to basically allow you to reverse this process so that you can go back
to the original primary key.
But the idea here is that you're putting a value out into the Web page that is on Lee Good in the context of the token vault, where the mapping can be placed back together again between that particular token for that session
and the primary key that's actually in the database
Now, in the demos, you saw some hard coating of the mapping being done in the application code. I wanted to just show you another way that it could be done.
So now we're gonna go ahead and move into the lab portion of our module