Part 5 Defenses
Video Activity
This lesson covers mitigations, countermeasures and defenses. The instructor discusses the following defenses: • Authorization checks • Tokenization • Combo (AuthZ and Tokens) This lesson also discusses tokenization, which maps a token in place of the direct object. In and of itself, the token is inert and harmless, of no value if it is taken out o...
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 covers mitigations, countermeasures and defenses. The instructor discusses the following defenses: • Authorization checks • Tokenization • Combo (AuthZ and Tokens) This lesson also discusses tokenization, which maps a token in place of the direct object. In and of itself, the token is inert and harmless, of no value if it is taken out of context.
Video Transcription
00:04
Hello and welcome to the side. Very secure coding course. My name is Sonny. Where and this is AWAS top 10 for 2013
00:13
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,
00:33
including the sequel statements for retrieving data sets,
00:38
files or directories and then, of course, application content, ensuring that it's viewable by only authorized users.
00:49
We'll also take a look at how we can use access controls in order to accomplish authorization checks.
00:58
So we'll speak about ankles and are back in other off ze codes that could be used
01:06
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.
01:26
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.
01:42
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.
02:01
So first, let's take a look at authorization checks in the database.
02:06
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
02:25
prior to the highlighted line,
02:29
you can see that we're just doing a select statement. We're selecting the product code
02:35
from the Prod table
02:38
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.
02:52
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
03:05
the viewing off this data set or the results set
03:10
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
03:30
prior to doing any kind of validation.
03:32
In addition to that, we can add ankles or access control. Lis.
03:38
This is really good, because what it does is insures that not on Lee
03:45
Are we validating against a fully resolved path,
03:50
but also that we are doing our proper authorization check to ensure that whatever that operation is is being performed by the authorized user.
04:00
Now the sample C c++ code that I have below
04:04
actually does a check against the full path First. Resolving that
04:11
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.
04:26
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
04:42
in this C sharp code. Example below, you can see that there's a check off the user's rolled
04:50
prior to the replacement of the location variable.
04:56
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
05:08
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
05:25
it's harmless or it's of no value to an attacker
05:29
if it's not used within the context off the mapping.
05:32
So if we go back
05:34
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
05:47
other reference number. Now there's different ways that you can do token ization.
05:54
If you look on the right hand side, you can see the rial primary keys for Tom, Bob and Alice.
06:00
Those have been replaced by some sort of generated token.
06:05
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.
06:25
This is just a code snippet to give you an idea of how a token ization service might be used.
06:31
So the first thing that you would do is you would query your database to get the actual primary keys first.
06:39
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
06:57
to the original primary key.
06:59
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
07:18
and the primary key that's actually in the database
07:23
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.
07:34
So now we're gonna go ahead and move into the lab portion of our module
Up Next
Instructed By
Similar Content
