Integrity Failures in Aspnet

Integrity failures in Aspnet applications occur when data modifications bypass authorization checks, allowing attackers to alter resources they shouldn't access. This manifests through several Aspnet-specific patterns.

The most common Aspnet vulnerability involves model binding without proper authorization. Consider an API controller handling product updates:

public class ProductsController : ControllerBase
{
    private readonly StoreContext _context;
    
    public ProductsController(StoreContext context)
    {
        _context = context;
    }
    
    [HttpPut("{id}")]
    public async Task UpdateProduct(int id, Product product)
    {
        var existing = await _context.Products.FindAsync(id);
        if (existing == null) return NotFound();
        
        // Critical vulnerability: no authorization check
        existing.Name = product.Name;
        existing.Price = product.Price;
        await _context.SaveChangesAsync();
        return NoContent();
    }
}

This code fails integrity checks because any authenticated user can modify any product. The model binding automatically populates the Product object from the request body without verifying the caller's permissions.

Another Aspnet-specific pattern involves improper use of Entity Framework Core's tracking. When developers retrieve entities and modify them without re-validating ownership, integrity failures occur:

[HttpPut("{userId}/profile")]
public async Task UpdateProfile(int userId, UserProfile profile)
{
    var userProfile = await _context.UserProfiles
        .FirstOrDefaultAsync(p => p.UserId == userId);
    
    // Vulnerability: assumes userId in URL matches authenticated user
    userProfile.Bio = profile.Bio;
    userProfile.Location = profile.Location;
    await _context.SaveChangesAsync();
    return Ok();
}

Even with authentication, this code trusts the URL parameter without verifying the authenticated user owns this profile. An attacker can modify the userId parameter to update other users' profiles.

Aspnet Core's attribute routing can also introduce integrity failures when route parameters are used without validation:

[HttpGet("{teamId}/members/{memberId}")]
public async Task GetMember(int teamId, int memberId)
{
    var member = await _context.TeamMembers
        .FirstOrDefaultAsync(m => m.TeamId == teamId && m.MemberId == memberId);
    
    if (member == null) return NotFound();
    
    // Vulnerability: returns member data without checking caller's team membership
    return Ok(member);
}

This exposes team member information to anyone who knows the teamId and memberId, regardless of their actual team membership status.

Detecting integrity failures in Aspnet requires both static analysis and runtime scanning. middleBrick's Aspnet-specific detection examines several critical areas.

For model binding vulnerabilities, middleBrick analyzes controller actions to identify patterns where:

• Model properties are directly assigned without authorization checks
• Entity Framework queries retrieve data without ownership verification
• Route parameters are used to access resources without validating caller permissions
• Database operations occur without checking user roles or claims

The scanner specifically looks for Aspnet's [Authorize] attribute usage patterns. Missing authorization on data-modifying endpoints is a primary indicator:

// Vulnerable: missing [Authorize] attribute
[HttpPut("{id}")]
public async Task Update(int id, Product product)
{
    // No authorization check
}

middleBrick also detects improper use of Aspnet's User property for authorization. Many developers retrieve the authenticated user's ID but fail to use it for ownership validation:

// Vulnerable pattern detected
var userId = User.FindFirst(ClaimTypes.NameIdentifier).Value;
// userId retrieved but never used for authorization

The scanner examines Entity Framework queries for patterns like:

// Detected vulnerability: no ownership check
var order = await _context.Orders.FindAsync(orderId);
// Direct database access without verifying caller owns this order

middleBrick's runtime scanning tests these endpoints by:

• Modifying request parameters to access other users' resources
• Testing authenticated vs unauthenticated access patterns
• Verifying response data exposure for unauthorized users

The tool specifically identifies Aspnet's anti-forgery token usage patterns, detecting when [ValidateAntiForgeryToken] is missing on state-changing operations.

Remediating integrity failures in Aspnet requires implementing proper authorization patterns using Aspnet's built-in security features.

The first defense is always attribute-based authorization:

[Authorize(Roles = "Admin,Manager")]
[HttpPut("{id}")]
public async Task UpdateProduct(int id, Product product)
{
    var existing = await _context.Products.FindAsync(id);
    if (existing == null) return NotFound();
    
    // Verify caller has permission to modify this specific product
    if (!CanModifyProduct(User, existing))
        return Forbid();
    
    existing.Name = product.Name;
    existing.Price = product.Price;
    await _context.SaveChangesAsync();
    return NoContent();
}

private bool CanModifyProduct(ClaimsPrincipal user, Product product)
{
    // Example: check if user is admin or owns this product
    if (User.IsInRole("Admin")) return true;
    
    // Check for custom claim or ownership property
    var userId = user.FindFirst(ClaimTypes.NameIdentifier).Value;
    return product.OwnerId == userId;
}

For data access patterns, always validate ownership before returning or modifying data:

[HttpGet("{userId}/profile")]
public async Task GetProfile(int userId)
{
    var profile = await _context.UserProfiles
        .FirstOrDefaultAsync(p => p.UserId == userId);
    
    if (profile == null) return NotFound();
    
    // Verify caller owns this profile
    var currentUserId = User.FindFirst(ClaimTypes.NameIdentifier).Value;
    if (currentUserId != userId.ToString())
        return Forbid();
    
    return Ok(profile);
}

Aspnet's resource-based authorization provides another layer of protection:

public class ProductAuthorizationHandler : 
    AuthorizationHandler
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context, 
        OperationAuthorizationRequirement requirement,
        Product resource)
    {
        if (requirement.Name == "Update" && 
            context.User.IsInRole("Admin"))
        {
            context.Succeed(requirement);
            return Task.CompletedTask;
        }
        
        // Check if user owns this product
        var userId = context.User.FindFirst(ClaimTypes.NameIdentifier).Value;
        if (resource.OwnerId == userId)
        {
            context.Succeed(requirement);
        }
        
        return Task.CompletedTask;
    }
}

// Controller usage
[HttpPut("{id}")]
public async Task Update(int id, Product product)
{
    var existing = await _context.Products.FindAsync(id);
    if (existing == null) return NotFound();
    
    var authResult = await _authorizationService.AuthorizeAsync(
        User, existing, 
        new OperationAuthorizationRequirement { Name = "Update" });
    
    if (!authResult.Succeeded)
        return Forbid();
    
    // Safe to modify
    existing.Name = product.Name;
    await _context.SaveChangesAsync();
    return NoContent();
}

For complex scenarios, implement policy-based authorization:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthorization(options =>
    {
        options.AddPolicy("OwnerOnly", policy =>
            policy.Requirements.Add(new OwnerRequirement()));
    });
    
    services.AddSingleton();
}

[HttpPut("{id}")]
[Authorize(Policy = "OwnerOnly")]
public async Task Update(int id, Product product)
{
    // Authorization handled by policy
    var existing = await _context.Products.FindAsync(id);
    if (existing == null) return NotFound();
    
    existing.Name = product.Name;
    await _context.SaveChangesAsync();
    return NoContent();
}