Tag: Security

IdentityServer is a .NET SDK for building an OpenID Connect and OAuth 2.0 identity provider on ASP.NET Core, issuing tokens to multiple clients and APIs. You need it for several apps or APIs, single sign-on, federation, or standards-based tokens. A single app with local users doesn’t; ASP.NET Core Identity suffices.

You can use passkeys as a second factor after password login in ASP.NET Core Identity on .NET 10. Register a two-factor token provider for users who have a passkey, then add two endpoints: one creates passkey request options for the user who passed the password check, and the other verifies the passkey before completing sign-in. Store the user id from the password step in a short-lived cookie, and compare it with the passkey’s user before signing in.

A session cookie is a bearer token, which is a polite way of saying that whoever holds it is you. Copy the cookie, replay it from another machine, and the server happily serves your account. Nothing about the request proves which device it came from, so a cookie lifted by malware, an XSS payload, or a stray database backup keeps working until it expires. For a long-lived session, that can be weeks.

Every time npm has a supply chain incident, it’s tempting to think “haha, npm had yet another supply chain attack!” and feel safe in .NET land. But the tools to do the same thing in .NET, or at least similar things, are all there. Module initializers, source generators, MSBuild targets, startup hooks. A number of techniques exist to smuggle code into someone’s codebase, and most of them run before your application’s Main method is even called.

For a couple of months now, I’ve been pondering about what tools are at your disposal in .NET to help build and execute a supply chain attack. My goal was to see what is available out there, and what we, as .NET developers, should be aware of. Prepare for a long read! Now, forget that short introduction, and let’s start anew…

We all know it’s important to prevent Cross-Site Request Forgery (CSRF) attacks against our application. Unfortunately, our inherited code base has zero measures implemented - not one action methods with a [ValidateAntiForgeryToken] attribute in sight!

As discussed in the previous post, we all know it is important to perform validations to prevent a Cross-Site Request Forgery (CSRF) attack against our application. Imagine inheriting a code base that has zero measures implemented? How would you find which action methods need a [ValidateAntiForgeryToken]? Today, we will look at using ReSharper to find all action methods that need [ValidateAntiForgeryToken] added. In this series:

As ASP.NET MVC developers, whether ASP.NET MVC 5 or ASP.NET MVC Core, we all know it is important to perform certain validations to prevent a Cross-Site Request Forgery (CSRF) attack against the application we are building. The ASP.NET MVC provides the @Html.AntiForgeryToken() helper which we can use to add a hidden field in the form we are posting, and a [ValidateAntiForgeryToken] attribute which we can decorate our action method with and instructs the framework to validate the posted token is valid (or was forged).

Earlier this week, a sad thing happened to the version control hosting service Code Spaces. A malicious person gained access to their Amazon control panel and after demanding a ransom to the owners of Code Spaces, that malicious person started deleting data and EC2 instances. After a couple of failed attempts from Code Spaces to stop this from happening, the impossible happened: the hacker rendered Code Spaces dead. Everything that was their business is gone. As they state themselves:

One of the services provided by the Windows Azure cloud computing platform is the Windows Azure Access Control Service (ACS). It is a service that provides federated authentication and rules-driven, claims-based authorization. It has some social providers like Microsoft Account, Google Account, Yahoo! and Facebook. But what about the other social identity providers out there? For example the newly introduced Login with Amazon, or LinkedIn? As they are OAuth2 implementations they don’t really fit into ACS.