.NET and ASP.NET penetration testing: Hardening C# enterprise applications

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

Why .NET security testing matters for Nigerian banking

Nigerian commercial banks operate hybrid architectures where modern cloud microservices connect to on-premises .NET applications built a decade ago. Those legacy ASP.NET WebForms and MVC applications run the transaction processing logic, the account reconciliation engines, and the SWIFT messaging interfaces. A vulnerability in a 10-year-old internal .NET app that was never exposed to the public internet becomes critical when a new API gateway or cloud integration punches a hole through the firewall to reach it.

1. Blazor WebAssembly decompilation

Blazor WASM applications ship the compiled .NET runtime and application DLLs to the browser. We download these DLL files directly from the network tab and decompile them using ILSpy. What we look for in the decompiled source:

• Hardcoded credentials: API keys, database connection strings, and internal endpoint URLs embedded in C# constants.
• Client-side authorization checks: Role checks or permission gates implemented as C# conditional logic in the WASM client, which can be bypassed by modifying the WASM binary or calling API endpoints directly.
• Business logic reconstruction: Understanding the complete transaction flow from decompiled C# helps identify where authorization shortcuts were taken in the API layer.

2. ASP.NET WebForms ViewState deserialization

Legacy ASP.NET WebForms applications encode page state in a hidden __VIEWSTATE form field. If the application does not enforce ViewState MAC validation (by setting EnableViewStateMac=true and configuring a strong machineKey), attackers can forge a ViewState payload containing a serialized .NET object that triggers Remote Code Execution when the server deserializes it during postback processing. We test every WebForms application for ViewState MAC enforcement and machineKey strength.

3. Entity Framework injection via raw SQL

Entity Framework Core's LINQ queries are parameterized by default. Injection risk appears in FromSqlRaw(), ExecuteSqlRaw(), and string interpolation inside SQL expressions. We search for every raw SQL execution path and test with injection payloads:

// VULNERABLE EF Core raw query
var userId = Request.Query["userId"];
// String interpolation bypasses EF parameterization
var users = db.Users
    .FromSqlRaw($"SELECT * FROM Users WHERE Id = {userId}")
    .ToList();

4. SignalR hub authorization

ASP.NET Core SignalR hubs provide real-time communication. Each hub method must declare authorization requirements using the [Authorize] attribute or validate the caller's identity inside the method. We test SignalR hubs for: unauthenticated connections, hub method invocation without caller identity validation, and group membership manipulation (can a client join a SignalR group they are not authorized to receive messages from?).

5. Anti-Forgery Token validation on state-changing requests

ASP.NET Core's anti-forgery token system prevents CSRF attacks on web applications. We verify that every state-changing controller action (POST, PUT, DELETE) validates the anti-forgery token, that the [ValidateAntiForgeryToken] attribute or the global AutoValidateAntiforgeryTokenAttribute filter is applied, and that API endpoints that accept credentials do not disable CSRF protection entirely.

Related reading

Blog: ASP.NET Core API security audit · Xamarin mobile app pentesting · SWIFT and ISO 20022 banking security

Services: Penetration testing · Secure architecture review