Tag: Security

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.

Earlier this week at Duende Software, we had a prospect reach out that wanted to implement IdentityServer in their solution. Their application consisted of one ASP.NET Core application with local users, no mobile applications or other clients, no API surface, and no plans in the roadmap to move towards an architecture with any of these. All they wanted was to add external authentication to Google.

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.

Many API’s out there, such as GitHub’s API, have a concept called “rate limiting” or “throttling” in place. Rate limiting is used to prevent clients from issuing too many requests over a short amount of time to your API. For example, we can limit anonymous API clients to a maximum of 60 requests per hour whereas we can allow more requests to authenticated clients. But how can we implement this?