Hello and welcome to the Siberian secure counting course. My name is Sonny. Where in this is sans Top 25 category.
Porous defenses. If you recall all top 25 issues, four Sands are actually categorized.
There are three main categories, including insecure interaction between components,
risky resource management
and porous defenses. This module we're focusing on pours defenses.
There are 11 issues in this particular category
ranking. 5678 10 11 15 17 1921 25. Let's take a look at them more closely.
So for ranking number five missing authentication for a critical function. We will take a look at that for rankings 678 1921 25.
We have already covered these subjects in other modules,
so missing authorization was actually covered in Module seven. That's missing function level access control.
And then all of the others have been covered in Module six
sensitive data exposure.
So that leaves us with 5 10 11 15 and 17
now first in overall definition for category.
Where's defenses category identifies weaknesses related to defensive techniques or secure coding practices that are often misused,
abused, ignored or misunderstood by the programmer.
So Now let's take a look
more closely at each of the issues that are left in our listing ranking. Five c w e three of six
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.
So this is an end memory database,
and you can see that the account used is saying which stands for system administrator of the highest
account, that you could possibly have to connect to a database
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.
So they use thes default accounts and then never go back and change in. The problem is that,
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.
So this is the type of thing that we never want our code to get past development with.
Now, the next explanation is for ranking 10 c w E 807 Reliance on Interested in puts in a security decision.
I actually have several examples for this, and so I'm going to step you through those now
at a high level unverifiable client side originated http. Request a response. Hitters
or any kind of client side inputs should never be relied upon for security decision.
So, for example, the setting of any information
at the client's side is susceptible to tampering.
The meta tags that you may use for cash control or refresh
an ending to the u R L
After the http, there's an ending semi colon, and then
also Java script validation that might be used for any kind of authentication or authorization checks
or illegal parameters, etcetera. All of those can be bypassed
if you have some sort of papa
that indicates that a particular character or particular value is not valid
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.
The next example is relying upon the HTP requests. Refer. This is a header that sometimes applications will use to check
in order to determine where the request is coming from, realized that it convey very easily be spoofed in any kind of proxy tool.
Now the next example I have continuing in this category of rain. 10. Reliance uninterested in puts in its security decision
is when you have a lack of input validation
for checking carriage returns or new lines.
Your Web application can be susceptible to http Response. Splitting
now Generally, the goal of http response Splitting is a cash poisoning or cross site scripting or something like that
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
and those air represented using the the U. R I encoding.
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.
And so the Web server thinks that the response is complete. However,
in to be is actually
in order to perform the next attack.
Now our next issue is rank 11 c W E to 50. This is execution with unnecessary privileges.
I have a couple of examples here. The first is file uploads ownership. We didn't speak about this in a previous module,
but basically by default,
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
to a much lower account, make it a no account that has very few privileges on the machine.
Another example that I'm putting here is a batch process user account,
so a lot of times they'll be two versions of an application.
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.
A lot of the cases when programs air writing that batch process,
they will just reuse the same application idea count that's being used by the online system. The problem with that is
it's probably way too privileged. So what the programmer needs to do is actually create a different account.
And if it's not up to the programmer, you just ask the d p a. To do it but
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.
Now ranked number 15 c W E 8 63 Incorrect authorization.
Here in this code snippet, we can see that the role is set in the cookie,
and that role is checked prior to displaying the nick the next sequential screen. All of this, of course, relying on information that set
and not performing any kind of validation on the server side. And so
they were e that any kind of information that you receive
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,
particularly when doing any kind of authorization checks.
And then the explanation for ranking 17 c W E 7 32
Incorrect Permission assignment for critical resource
in this example. Here you see the make directory function is missing the mod argument or, in other words, the Shimada.
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.
So that's going to make anything in that directory. Execute Herbal
Now the case studies from Dark Reading.
This is entitled Web App Developers Putting Millions at Risk. What this is about is
back end as a service systems where
application developers are synchronizing
information in their Web application with some sort of back end as a service provider that is in the cloud.
The problem is that they are actually embedding thesis e crit key within the code that synchronizes with that back in system.
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
and so easily known it's not being changed or anything like that
makes it susceptible to very easily being lifted.
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
now realize that the vendors themselves provide documentation
on how the programmers should be secure, securing that information,
changing those keys, et cetera.
But this information, unfortunately, seems to be getting ignored by the development team.
Now let's move on to the demo portion of our module.