Intro
Hello, and welcome to today's post on detecting third party package vulnerabilities in the .NET and JavaScript space.
In this post, we delve into the realm of package vulnerabilities, exploring. We also take a look at how the .NET and JavaScript leverage tools to address these vulnerabilities. What does Github have to do with all of this, and how can I get started on detecting dependency vulnerabilities today?
Vulnerable?
To define a vulnerable dependency, lets look at the word vulnerable in the app security context.
The OWASP website states that a vulnerability is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. (Link here)
Pretty straight forward, to be fair. So for our situation, there's code out there in third party packages that are made in a way which can be exploited by either the author or other attackers who are accessing the application which uses that package.
I like the phrase shared in "Alice and Bob Learn Application Security" regarding assessing the security of third party applications: "if it is insecure, your application is now also insecure".
Types of vulnerabilities
Much like the love that parents show their children, not all vulnerabilities are equal (did I share too much?😐). There are two main types:
- Known
- Unknown
Known vulnerabilities
Consider a situation where you have decided to install an open source application in your computer. In this situation, you may be fully confident that you wouldn't need to be worried about any potential security issue that may arise because it's "public" for everyone to see, and any code written could be immediately detected and reverted.
You're half right, but what about it's third party dependencies? This is where the concept of the known vulnerability comes in. It's a type of vulnerability that is known by the public, an example in this situation is an open source code that has dependencies with known ways of hacking it. Going back to the Alice and Bob book, the open source app is now hack-able too.
Other examples could include things like an exposed storage account that allows anonymous reads and writes when it's not supposed to, or an api missing authentication/authorization controls. Examples taken from this excerpt here.
Unknown/Unique vulnerabilities
The opposite case comes in the form of software that is "custom" and potentially not "exposed to the public" in a sense. The word "custom" in this case bares the meaning of being containing unique enough code that makes vulnerability discovery all the more of an effort; as opposed to already discovered ones by the public.
An example of this would include a situation where the company person A works for has unknowingly released vulnerable code. Given the unlucky times companies find themselves in, they happen to run into an attacker with a specific set of hacking skills that are exactly in the area that vulnerability is "suited" for. And so, they discover the unique way to expose this vulnerability from the application and start wreaking havoc.
In this particular segment, since the main subject is about securing third party dependencies, we'll be talking mostly about known vulnerabilities and how to avoid them.
Best practices
We'll be looking at detecting and avoiding known vulnerabilities in third party dependencies in two languages:
- CSharp
- JavaScript
Both use very similar ways of detecting third party package vulnerabilities, and are also able to utilize very well known tools the same way. As a result, each section of best practice will mention how it's done for both the .NET framework and JavaScript.
Nuget - CSharp
For those not in the .NET space, Nuget is a development tool that is used by developers to package, publish and consume code in the public sphere. It's also a software used to keep a track of what your project has installed, what needs updating etc.
In regards to tackling this issue within the .NET space, it's safe to say that this third party dependency management software is the main area we will focus on. As of this moment, the current GitHub Advisory Database shows that there are currently 560 security issues detected within certain third party packages published to Nuget.
Having this information is vital, in that it allows us to know what packages and versions of those packages are currently dangerous to use, or roll back/forward from in some unavoidable situations. This is good news, but how exactly do we take advantage of this in Nuget?
Luckily for us we, Nuget already has this feature built into it's software. As pointed out by Drew Gillies in this post, Nuget get's it's info directly from Github. So there's less chance of the package information being out of date or incorrect.
Of course, you may also be a terminal type of person, and that can also be addressed through the use of .NET CLI.
dotnet list package --vulnerable ---include-transitive
This get's your direct packages, as well as your packages' dependencies. This way, you can see exactly which package needs to be upgraded.
NPM - JavaScript
Now, for those that are not in the JavaScript space, NPM stands for Node Package Manager. It's essentially what Nuget is for the .NET space; a public library registry for JS based packaged code.
Just like Nuget, NPM also uses the Github Advisory Database to power it's reports and package vulnerability detection. It used to have it's very own NPM advisory database, however it later it began solely relying on Githubs version (Circa 2021).
The process is pretty much the same for javascript users in that they can simply run the npm audit command. This will generate a report of any known vulnerabilities within your dependencies list. This includes direct dependencies, devDependencies, bundledDependencies, and optionalDependencies, but does not check peerDependencies..
There's no need to run this separately from npm install, as part of the npm install process also runs this audit command. Two for the price of one!
While in GitHub
You can also automatically get GitHub to check for any list of dependencies at risk. This can be done via turning on the Dependabot option in the settings of your GitHub repo.
It's a fairly simple process that can be followed in this example here if you don't want to have a no code solution to the issue of detecting vulnerabilities. However if you do, then it can also be done via the use of yaml files, but letting GitHub deal with that is better in my opinion; less need for us to waste time on it and more time working on our app.
Conclusion
This is what this post is all about, we managed to take a look at the concept of package vulnerabilities and the different ways it presents itself; being known or unknown. We've also seen how both the .NET and JavaScript worlds use certain tools to deal with these vulnerabilities. Both of which are tied to a very popular GitHub Advisory Database which keeps track of all the known vulnerabilities, and can automatically scan/reports on our app dependency vulnerabilities so we don't have to.
I hope you enjoyed and learned from this post, I know I did 🙌 Until next time, in the next post and in the next learning opportunity 👋
Top comments (0)