Part 4 Defenses
Video Activity
This lesson covers mitigations, countermeasures and defenses. Participants learn about the following defense methods: • Configurations • Integrity checks • Canonicalize path/files • Create and monitor thresholds Participants learn some sample code to use the defense methods.
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. Participants learn about the following defense methods: • Configurations • Integrity checks • Canonicalize path/files • Create and monitor thresholds Participants learn some sample code to use the defense methods.
Video Transcription
00:04
Hello and welcome to the saw debris re secure coding course.
00:08
My name is Sonny Wear, and this is Sam's Top 25 category. Risky resource management,
00:16
mitigations, countermeasures and defenses. So, first, our defenses overview.
00:22
We're going to look at configurations that can make your Web server and your Web application more secure.
00:31
Now, a lot of times Web server configurations may just be performed by the assisted system administrators.
00:39
But configurations related to the Web application will usually fall to developers. And so we're gonna look at what some of those settings might be.
00:48
Also in the defense's overview.
00:51
Well, look at integrity checks that can be done.
00:55
If you are receiving code from 1/3 party, it should be signed by that third party. And so there should be some sort of verification done
01:07
as well as check sums. If you do any downloading of the alleles or jar files from third party Web sites,
01:15
then we'll look at the programmatic, canonical ization
01:21
of paths files that make him into your program. We know that we have to Connecticut lies before we actually perform our validation on these external sources coming into our program,
01:36
and then it regards to the denial of service attacks. It's important that we create and monitor our thresholds even within our code.
01:46
Now we should think about either limiting or eliminating the sourcing in of external You are ells. If this cannot be avoided,
01:57
then we should at least guard that the particular
02:01
extremely referenced you a rail
02:05
is known is authenticated against each time, et cetera, that we've got some layers of security in place to protect us.
02:15
And then finally, we want to make sure that we're monitoring our database connection. Pooling that are CPU usage is not spiking too much that basically we have the capacity to enable appropriate throughput for the peaks that we may see in volumes. And, of course,
02:36
pastie planning is something that should be done, at least on an annual basis. If your business continues to grow.
02:44
So no looking at our configurations in more detail for the Web server, we can see that
02:51
there are going to be some settings at the Web server level that would have to be applied.
02:58
Now I have here Apache and I I s
03:02
being probably the two most popular,
03:06
but you can see here that you have to go into the configurations or the managers and apply particular settings.
03:16
And so, for your particular Web server, please consult the documentation. But basically what you're doing is you're turning off
03:25
directory browsing. You want to disable the viewing of files to unauthorized eyes.
03:35
Now in a similar fashion, you conduce this for your Web application.
03:39
You can see that I have here IBM WebSphere configuration that can turn directory browsing to fault
03:47
and then for Tomcat as well.
03:51
The reason why this is actually separated because you might be thinking, Well, if you do it at the Web server level,
03:59
why do you have to even bother at the Web application level? And this really could be a choice? Maybe there are particular pages that you wish to be directory browsing
04:13
enabled
04:15
maybe four reading whizzed ALS or reading Web service configuration files and things like that. So that's why the option is made available to you now for integrity checks.
04:30
There are basically two defenses that I'm labeling here. The signing of code and actual Searcy checks
04:39
the signing of code. This is generally done by the vendor that is wrapping a shrink, wrapping the code and delivering it
04:48
to you
04:50
and
04:51
what you would like to see happen is a an actual private key signing of that code by the trusted source or the the vendor, the person that wrote that code
05:05
and then a wrapping around of that private key with the public key. And you want that public key to be verified by some sort of certificate authority. Usually, it's thought or
05:19
their sign or could even be your own company if they have become their own. C A.
05:26
Just make sure that it's not a self signed certificate, which basically cannot be verified.
05:31
And so for the integrity checks.
05:34
If you go to download any of these files,
05:39
whether it's an ear CSI jar file a DLL
05:45
usually at the more reputable sites, you're going to find some sort of check some there. It should be
05:53
a shot to 56 or something like that, and so you can use
05:58
several free tools that are available. There's one available and seven zip
06:02
as well as other tools
06:04
that allow you act. You download
06:08
the
06:09
the particular library.
06:11
You can just right click that library,
06:15
select the particular hashing function that was used
06:18
and it will calculate the check. Some four use. You can verify that what you downloaded actually matches what the site is stating. It should be. And this, of course, is to verify him. Validate that. No malware has been wrapped
06:34
with that. Execute herbal as well.
06:36
Now, Connecticut Rising paths.
06:40
Two files.
06:42
This is the defense for the inclusion of functionally from untrusted controls. Fear.
06:46
We've talked about this before, but just as a quick recap
06:53
we want to Connecticut lies all of our path names. And what that means is
06:58
that we want to resolve fully resolve against the file system all absolute or relative file paths.
07:08
So we don't want to use shared directories. And we had talked about that before,
07:12
changing landing zones and jailing down file locations so that users cannot change directory paths and things like that.
07:23
And of course, we never want to use arguments directly in our code
07:27
to determine where particular file is located.
07:30
Because we know that that could that could be an attacker controlled path. And so if you see the sample code at the bottom,
07:41
you can see that first you want to check that argument that comes into your code. Don't use that argument directly to determine the path. Step number two.
07:51
Use a canonical path method
07:56
or some sort of way that your language supports canonical izing,
08:00
where it will actually verify
08:03
the path thing to the final system.
08:05
And then step number three. Then you couldn't go ahead and perform your validation. What is it that you're actually looking for?
08:13
Well, we're looking for
08:15
a file named final one dot t x T that's supposed to reside in an image job, a directory, for example.
08:22
Now the other thing that I have included here to address the inclusion of functionally from untrusted controls fear is that we did talk about
08:33
denial of service attacks.
08:35
We also talked about the limiting of or the limitation of
08:41
database connection pools as well as other types of resource pools that basically you want to limit based upon the hardware that you're running underneath.
08:52
So I have here a couple of
08:54
ah, a couple of the counter measures that could be used first, of course, in regards to the sourcing of external ur Els,
09:03
we had looked at an example of Google analytics, so if you cannot actually eliminate the sourcing of external your rails. What you may want to look into is using a nonce
09:16
for that you are rail for the use or inclusion of that. You are well in your page.
09:22
Now,
09:24
the nonce is it's not going to protect you
09:26
from that actual external u R l actually being infected.
09:33
The only thing is gonna protect you from is that you know,
09:37
uh, that is theatrical.
09:41
That is the actual your l or that is the actual source that you do want to include in your page and it is external. So
09:50
if an attacker injected something malicious, it would stand out, it wouldn't have the knots
09:58
now And, of course, he announces,
10:01
is a one way hash that can distinctively identify a certain object. Now, in this case, you are well
10:09
now in regards to the monitoring of your database connection pooling or your other resource pooling CP CPU usage, etcetera.
10:18
What you always want to do is profile your programs, and this is usually done
10:26
in an environment that's a little bit more robust in development.
10:31
Usually it's your pre production environment.
10:33
You can use tools like J profiler, other profiling tools that can actually look and see
10:41
where the majority of your calls are coming from. How efficient
10:45
those calls are
10:46
are going through the stack going through the heat.
10:52
How cleanly your program is is getting. Resource is cleaned up as objects are completed from being used in the methods.
11:05
So that's what you see on the left. On the right. I have a picture of ganglia. This is a,
11:13
uh,
11:13
this is a very good
11:15
profiling tool for the CPU itself. It'll look at the underlying hardware to look at the memory available.
11:22
It'll look at
11:24
heap sizes
11:26
as programs are run and how much is being used, how much is available.
11:31
And so these are the types of tools that you'll want to have available in order to monitor for any kind of
11:39
denial, denial of service attacks
11:43
or the watching of your connection pools to see if you are getting low on resource is
11:52
now we're going to go into the lab portion of our module
Up Next
Instructed By
Similar Content