As we write this article, the latest version of .NET Core is version 3.1.1, so we are writing it in that context. But this is an overview that reflects on the overall security of the .NET Core Framework and the principles discussed are backward and forward compatible with other .NET Core versions.
Is .NET 3.1 Secure?
The short answer is “yes.” The longer answer is that — just like with any development framework — .NET Core is as safe as the development best practices and maintenance deployed to create the code and keep it updated. But in a way, .NET Core is more safe and secure than previous frameworks. Think about it this way ….
An Infamous Anniversary for Internet Security
As long as there have been computers and networks there have been people intent on illegally accessing and disrupting them. But the modern age of computer crime began almost exactly twenty years ago when — on February 7, 2000 — a fifteen-year-old in Canada launched the very first documented DDoS attack.* His targets were Amazon and eBay. The guardians of the internet have been scrambling ever since.
Microsoft gave birth to the ASP.NET web framework two years later in January of 2002. As a new generation of cyber pranksters and criminals came up in the age of the internet, ASP.NET was actively updated and developed at the same time. And as the advents of mobile, social, cloud, and “big data” each took their disruptive turn on the technological stage, ASP.NET kept pace right alongside with security patches and updates to keep environments safe. But this means that security measures and new authentication methods were added in over time — expanding the code base and adding complexity.
Why .NET Core is Better for Security
If you’ve ever tried to update an old house, you know that it can be challenging. As we’ve learned more about home construction and materials we have updated building codes and standards to ensure that modern homes have far few troubles and are far more efficient. .NET Core is the same thing.
Microsoft built .NET Core from the ground up with twenty years of lessons learned and updated best practices built in. Application and website security are not add-ons and patches. Security was a fundamental attribute of design and structure which means we can build more secure apps with less complexity and faster performance. And this is especially important in the age of platforms and the cloud when APIs and service calls are flying back and forth to keep your business tech connected to the world at the speed of light.
Importantly, one of the lessons Microsoft learned was to always be looking forward. So even though .NET Core was built to be cloud-native, they were also looking at the fledgling technologies of connected devices (IoT) and edge-computing. So, this forward-looking technology is wired in as well.
In other words, many of the same things that make .NET Core orders of magnitude faster than previous .NET iterations also make it more secure.
Security Best Practices for .NET Core 3.1
That said, installing a new deadbolt on your front door is great unless you forget to lock it.
Security is still in the hands of the developers and admins who write, deploy, and maintain the applications. The best practices that have been developed over the last two decades – some of which we’ve documented over the years — are still best practices. .NET Core 3.1 just makes them easier to deploy, easier to maintain, and faster to run.
The basics still apply, including:
Manage Your Identity Providers in .NET 3.1
Great security starts with keeping the black-hats out and letting the good guys in to do business. Before we talk about things like authentication, we need to start with the tools to do that user authentication. .NET Core 3.1 natively includes Identity providers. But it also supports major third-party identity services, including from the major social networks (e.g., Facebook, Twitter, LinkedIn). You can find an introduction to Identity in .NET Core 3.1 here.
Authentication First / Authorization Second
Old-school applications used to focus on Authorization — which allowed users to access certain functions or features based upon roles first. But once given any degree of access, a system is less secure if that individual has bad intent.
Authentication is a strict protocol of verifying an individual’s identity first and preventing access entirely unless their credentials match. An overview of Authentication in .NET Core 3.1 along with additional references can be found here, and additional information on Authorization can be found here.
Enforce HTTPS
Deploying HTTPS is not the same as enforcing it.
Encryption keys used to cost money. But we live in a time when adding encryption to your web application is either free or VERY inexpensive. Three years ago we wrote extensively about great services like LetsEncrypt that offer free basic encryption. But there are a surprising number of sites that still have no encryption at all and many that do offer it as a security to visitors but do not enforce it as a security for and across the application itself.
Also written at the time, we have a white paper resource that discusses this and other important related topics — including some of the most common vulnerability types.
Most Common Vulnerability Types
There are dozens of known vulnerability vectors. Some of the most common types apply to a majority of business websites. According to Microsoft, the most common vulnerability types to guard against in .NET Core 3.1 are as follows:
- Cross-Site Scripting (XSS) — An attacker places client-side scripts inside vulnerable website code, allowing the interception of cookies or access tokens. You can read more about this on Microsoft’s website.
- SQL Injection — An attacker places executable database statements in an entry field. This is one of the most common attack types today. To protect your site, read the warnings on Microsoft’s Raw SQL Queries page or call us if you still have questions.
- Cross-Site Request Forgery (XSRF) — An attacker takes advantage of a previously authorized session. To learn more about
- Open Redirect — Page/URL redirects are important tools in the hands of coders. But vulnerable websites can have redirects tampered with to point to a malicious URL. Information on preventing this kind of attack can be found on Microsoft’s website.
As we stated, there are many more potential vulnerabilities. Contact us if you need a more comprehensive listing and to see which might apply to your application.
Maintenance & Updates
.NET Core is updated regularly with new features, fixes, and important patches. The number one most important way to keep your .NET Core websites and applications safe and secure is to ensure that they are running the latest versions. As we write this article, .NET Core 3.1.1 was released on January 14, 2020. Since 3.1.x is a long-term-supported (LTS) version it will be kept current with security updates for the foreseeable future. All websites and applications — no matter their framework of coding language — should be kept up to date on the latest supported versions.
Summary — .NET Core 3.1 Is Safe & Secure
It is our opinion that the latest version of .NET Core 3.1.x is the safest and most secure development platform available today for creating business-class and enterprise-class websites and applications. But as with all development frameworks, deploying best practices and proper maintenance are key.
If you want to check your site for vulnerabilities we can help you run a vulnerability and security compliance scan and explain the results (shoot us a note).
Thanks for reading.
* Yes, we are aware that the first computer DoS occurred in 1974 at the University of Illinois and that some sources cite a 1999 local-network disruption at the University of Minnesota as a DDoS attack. But both of those are not really the same thing and do not change the point. See the links below for more information.
Additional Links & Resources for Security & .NET Core 3.1
Microsoft’s Overview of ASP.NET Core Security.
Radware wrote up a short history of DDoS attacks.
We like Britannica’s background info on DDoS better.
Wikipedia cites different events in the history of DDoS, but documentation is sketchy.