Part 2 Explanations
Video Activity
This lesson begins with the definition of porous defenses. This category identifies weaknesses related to defensive techniques or secure coding practiced that are often misused, abused, ignored or misunderstood by the programmer. Missing authentication for critical function is when a blank or empty password is used to access a database. Participant...
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 begins with the definition of porous defenses. This category identifies weaknesses related to defensive techniques or secure coding practiced that are often misused, abused, ignored or misunderstood by the programmer. Missing authentication for critical function is when a blank or empty password is used to access a database. Participants receive an example of some sample code to accomplish this. This unit also discusses and offers samples of: CWE 807 Reliance on Untrusted Inputs in a Security Decision CWE 250 Execution with Unnecessary Privileges CWE 863 Incorrect Authorization CWE 732: Incorrect Permission assignment for critical resource Finally, a case study about web app developers placing millions of users at risk is presented, citing a case in which German security researchers discovered 56 million data records lying unprotected in cloud back-end security databases.
Video Transcription
00:04
Hello and welcome to the Siberian secure counting course. My name is Sonny. Where in this is sans Top 25 category.
00:12
Porous defenses. If you recall all top 25 issues, four Sands are actually categorized.
00:21
There are three main categories, including insecure interaction between components,
00:27
risky resource management
00:29
and porous defenses. This module we're focusing on pours defenses.
00:34
There are 11 issues in this particular category
00:38
ranking. 5678 10 11 15 17 1921 25. Let's take a look at them more closely.
00:49
So for ranking number five missing authentication for a critical function. We will take a look at that for rankings 678 1921 25.
01:03
We have already covered these subjects in other modules,
01:07
so missing authorization was actually covered in Module seven. That's missing function level access control.
01:15
And then all of the others have been covered in Module six
01:21
sensitive data exposure.
01:23
So that leaves us with 5 10 11 15 and 17
01:27
now first in overall definition for category.
01:32
Where's defenses category identifies weaknesses related to defensive techniques or secure coding practices that are often misused,
01:42
abused, ignored or misunderstood by the programmer.
01:47
So Now let's take a look
01:49
more closely at each of the issues that are left in our listing ranking. Five c w e three of six
01:57
missing authentication for a critical resource in the example that I'm showing here, you can see that a blank or empty password is actually used in the connection string used to connect to the database.
02:15
So this is an end memory database,
02:17
and you can see that the account used is saying which stands for system administrator of the highest
02:25
account, that you could possibly have to connect to a database
02:30
and that the password is completely blank Now this can happen, and it generally happens when developers grab some code off of the Internet or a sample from documentation. They want to get something up and running quickly.
02:47
So they use thes default accounts and then never go back and change in. The problem is that,
02:55
unfortunately, these accounts and this embedded code stays in the bundle and generally is probably propagated all the way to production unless somebody catches it.
03:07
So this is the type of thing that we never want our code to get past development with.
03:15
Now, the next explanation is for ranking 10 c w E 807 Reliance on Interested in puts in a security decision.
03:24
I actually have several examples for this, and so I'm going to step you through those now
03:31
at a high level unverifiable client side originated http. Request a response. Hitters
03:38
or any kind of client side inputs should never be relied upon for security decision.
03:46
So, for example, the setting of any information
03:51
at the client's side is susceptible to tampering.
03:54
The meta tags that you may use for cash control or refresh
04:00
could be susceptible to tampering by JavaScript methods. You can see there in the example that after the meta tag,
04:09
there's actually
04:11
an ending to the u R L
04:14
After the http, there's an ending semi colon, and then
04:18
the u. R L is equal to and and we have it set to an actual attack. So this is some JavaScript attack
04:27
also Java script validation that might be used for any kind of authentication or authorization checks
04:35
or illegal parameters, etcetera. All of those can be bypassed
04:41
if you have some sort of papa
04:44
that indicates that a particular character or particular value is not valid
04:50
and all of that is being done on the on the client side. It can be easily circumvented, and you will see that in the demo a swell.
05:00
The next example is relying upon the HTP requests. Refer. This is a header that sometimes applications will use to check
05:10
in order to determine where the request is coming from, realized that it convey very easily be spoofed in any kind of proxy tool.
05:21
Now the next example I have continuing in this category of rain. 10. Reliance uninterested in puts in its security decision
05:31
is when you have a lack of input validation
05:36
for checking carriage returns or new lines.
05:40
Your Web application can be susceptible to http Response. Splitting
05:46
now Generally, the goal of http response Splitting is a cash poisoning or cross site scripting or something like that
05:57
at a high level.
05:58
How this attack occurs is if you start with bubble number one, you can see that there's an original request that has been tainted with some carriage returns in new lines
06:11
and those air represented using the the U. R I encoding.
06:17
Now, what has crafted in that tainted request is actually a fake response. So when the Web server sends to a back, it will have a 200 okay, in the response that was part of the tainted request.
06:33
And so the Web server thinks that the response is complete. However,
06:41
in to be is actually
06:44
another portion of that response that actually carries the payload. So it might be JavaScript
06:49
in order to perform the next attack.
06:54
Now our next issue is rank 11 c W E to 50. This is execution with unnecessary privileges.
07:03
I have a couple of examples here. The first is file uploads ownership. We didn't speak about this in a previous module,
07:12
but basically by default,
07:14
the files that get uploaded it gonna be owned by the user. That's running the Web server. So you want to make sure that you script or code some way to change the ownership of those files
07:28
to a much lower account, make it a no account that has very few privileges on the machine.
07:35
Another example that I'm putting here is a batch process user account,
07:40
so a lot of times they'll be two versions of an application.
07:45
They'll be the online version of the Web application itself, and then there'll be a batch version, which does generally loads in the middle of the night to load data that it receives from clients.
07:58
A lot of the cases when programs air writing that batch process,
08:03
they will just reuse the same application idea count that's being used by the online system. The problem with that is
08:13
it's probably way too privileged. So what the programmer needs to do is actually create a different account.
08:20
And if it's not up to the programmer, you just ask the d p a. To do it but
08:26
to create a lower, privileged account that has fewer grants associated with it. And that's the account with that would always be used for any batch processing.
08:37
Now ranked number 15 c W E 8 63 Incorrect authorization.
08:43
Here in this code snippet, we can see that the role is set in the cookie,
08:50
and that role is checked prior to displaying the nick the next sequential screen. All of this, of course, relying on information that set
09:01
on the client side
09:03
and not performing any kind of validation on the server side. And so
09:09
they were e that any kind of information that you receive
09:13
back from your browser, even if you said it on the server side. Initially, make sure that you do some kind of validation to make sure that that information has not changed from what you expected,
09:26
particularly when doing any kind of authorization checks.
09:30
And then the explanation for ranking 17 c W E 7 32
09:37
Incorrect Permission assignment for critical resource
09:41
in this example. Here you see the make directory function is missing the mod argument or, in other words, the Shimada.
09:50
So what that means is, when the directory gets created, it's going to have default commissions of 777 which for those that do not speak UNIX, that is going to be wide open.
10:03
So that's going to make anything in that directory. Execute Herbal
10:09
Now the case studies from Dark Reading.
10:11
This is entitled Web App Developers Putting Millions at Risk. What this is about is
10:20
back end as a service systems where
10:24
application developers are synchronizing
10:26
information in their Web application with some sort of back end as a service provider that is in the cloud.
10:37
The problem is that they are actually embedding thesis e crit key within the code that synchronizes with that back in system.
10:46
So even if information maybe going over a secured protocol like T. L s the fact that this key is directly embedded in the code
10:58
and so easily known it's not being changed or anything like that
11:03
makes it susceptible to very easily being lifted.
11:07
And so
11:09
this article basically goes into the level of risk that's being created by programmers who are using these back and as a service. Systems
11:18
now realize that the vendors themselves provide documentation
11:24
on how the programmers should be secure, securing that information,
11:28
changing those keys, et cetera.
11:31
But this information, unfortunately, seems to be getting ignored by the development team.
11:37
Now let's move on to the demo portion of our module.
Up Next
Instructed By
Similar Content
