Hello and welcome to the side. Very secure coding course.
My name is Sonny wear, and this is Awash Top 10 for 2013
a nine using components with known vulnerabilities. So first we'll take a look at a definition for this category.
The term components in the title of this category
refers to application frameworks, libraries or other software modules integrated into an application.
Such components are usually written by 1/3 party.
This category references using thes components when they may have malicious code or security weaknesses within them. Now, if we take a look at the A WASP chart for a nine using components with known vulnerabilities,
we can see that the attack vector exploit ability is
Also, we can see that the impact is moderate.
Now, if we take a look at what's said about the security weakness, AWAS states the following
Virtually every application has these issues because most development teams don't focus on ensuring their components or libraries are up to date.
In many cases, the developers don't even know all the components they are using. Never mind their versions. Component dependencies make things even worse. If we take a look at our first code sample. This is actually from Java.
This is a static block that is loading 1/3 party DLL.
Now it could be that this DLL is from a vendor and was purchased or could certainly be a dll from an open source. But in either case, it really needs to be scanned or att least
verified in some way
that it is free of vulnerabilities.
One way to atleast identify if vulnerabilities air present is to search for the name of the DLL
on the C V s s or the C V e website,
the National Vulnerability database references C V E numbers
and within those TV e numbers will be a CVS s score.
We're actually going to take a look at how to do this in the demo, and you will have a lab assignment to do that as well. But the point here is that many times as developers, we blindly trust
the accepting of third party code
and immediately loaded into memory as this is being done in the static block.
One of the thing I want to make note of is the use of jar files
Java applications where the code has been written over several years. We can reference jar files of open source packages that are actually very out of date.
This is commonly done not out of any malicious intent, but just negligence. There are newer versions of those jar files that we should instead be using. And really, it just takes some discipline to go through that list or go through your palm file
and go ahead and update all of those dependencies. Now the next code sample that we have is from C Sharp.
This is importing vendor libraries
and in this one were actually
having the using statement import a vendor library. What we need to do in this case if we don't have access to the source code as we do in an open source version of a library,
is to actually challenge the vendor, the third party where we purchased this library
to share vulnerability scans or provide some sort of security posture statement
that ensures that their library or libraries are clean of any security vulnerabilities. Now the case study is on Adobe Flash. This is a vulnerability in adobe flash that came to be known
through the hacking team breach.
This vulnerability can actually allow an attacker full control of the victim's machine. If we take a look at the details in the C B E,
we can see that there's a C V E number referenced here.
And what state is that? Adobe Flash player, And it gives the version And earlier versions for Windows, Macintosh and Lennox have a successful exploitation that could cause a crash and potentially allow an attacker to take control of the affected systems.
So we could actually look this up and Google the CVI number to find out more details and regards to its CBSS score severity and affected modules.