.NET ASP.NET ASP.NET Core Security Application Security DevSecOps .net core C#
Amersfoort, Utrecht, Netherlands
Niels Tanis has got a background in .NET development, pentesting and security consultancy. He also holds the CSSLP certification and has been involved in breaking, defending and building secure applications. He joined Veracode in 2015 and right now he works as a security researcher on a variant of languages and technologies related to Veracode’s Binary Static Analysis service. He is married, father of two and lives in a small village just outside Amersfoort, The Netherlands.
In the early days, breaking into systems (hacking) mostly consisted of finding machines that where connected to the internet and exposed all their services. In some way the industry became better in locking down infrastructure and access and the attacks focused more on applications finding issues like SQL injection and Cross-Site Scripting. With the latest move to ‘DevOps’ and the use of build pipelines for CI/CD, with Azure DevOps or GitHub Actions, attacks even have become a lot more sophisticated. What if the used container images and/or 3rd party libraries contain vulnerabilities? With cloud native approaches like Azure Functions our application landscapes have become a lot more complex giving hackers more opportunities because of the increased attack surface. All steps we need to take to develop, test and release our software can be referred to as the software supply chain, which has become a lot more complicated.
In this session we'll take a .NET application and go through the different area's of the supply chain, identify the security issues, and possible ways of resolving those issues!
When developing a .NET Core application a large portion of the application itself consists of external 3rd party dependencies which can be fetched from a package repository like Microsoft's NuGet.
How do those opensource projects/dependencies deal with security problems? We do need to keep an eye on security updates done in order to not introduce any unnecessary security risks into our application but will that be sufficient?
Finding and resolving security issues can take a lot of time and what about a compromised package in which a contributor has added functionality which has got malicious intent?
There is definitely a away we can improve the above and do a better job! In this session we'll take a look at e.g. compartmentalization and API review/reduction of those dependencies in order to reduce the risk profile of our developed .NET Core Applications.
With Blazor we get a new full-stack way of building web apps with .NET and C#. It can be used in different ways like rendering it on a server (Blazor Server) to running it fully inside of the browser with the help of WebAssembly. A big benefit of this full-stack approach is that code can be written in C# and shared across all different execution contexts.
With each different application architecture comes different security problems. For example, when run on a centralized server we probably need to worry more about used resources and availability. When fully run on a client we're more concerned about the way it stores local data and how it uses and/or communicates with back-end services.
In all of the different application architectures we want to take the right decisions during the whole application lifecycle so that our organization won't face any unnecessary security risks.
In this session we'll look into some of the inner workings of the different ways (application architectures) Blazor can be used and work out a threat model that identifies the possible security issues for that architecture. And this session of course won't be complete without possible solutions that will mitigate/reduce the risk of the found issues!