Bola Idor with Hmac Signatures

BOLA (Broken Object Level Authorization) and IDOR (Insecure Direct Object Reference) vulnerabilities occur when an API fails to properly verify that a user has permission to access specific objects. In HMAC-signed APIs, these vulnerabilities can manifest in subtle ways that bypass the cryptographic integrity checks.

The core issue arises when HMAC signatures authenticate the integrity of a request but not the authorization of the resource being accessed. Consider a typical HMAC workflow:

const hmac = crypto.createHmac('sha256', secretKey);
hmac.update(method + '&' + path + '&' + timestamp);
const signature = hmac.digest('base64');

An attacker can exploit this by:

1. Capturing a valid HMAC-signed request for their own resource
2. Modifying the resource identifier in the request (e.g., changing user_id from 123 to 456)
3. Resending the modified request with the original HMAC signature
4. Since the signature validates the request structure but not the resource ownership, the server processes the unauthorized access

Here's a concrete example of vulnerable HMAC implementation:

// Vulnerable endpoint - only verifies HMAC, not resource ownership
app.get('/api/users/:userId', (req, res) => {
  const { userId } = req.params;
  const { signature, timestamp } = req.headers;
  
  // Verify HMAC signature
  const isValid = verifyHmacSignature(req.method, req.path, timestamp, signature);
  if (!isValid) {
    return res.status(401).json({ error: 'Invalid signature' });
  }
  
  // PROBLEM: No check that userId belongs to authenticated user
  const user = await getUserById(userId);
  res.json(user);
});

The vulnerability becomes more dangerous when APIs use predictable resource identifiers or when the HMAC key is shared across multiple services without proper scoping. Attackers can systematically enumerate resource IDs by:

• Using timestamps and other predictable values in HMAC inputs
• Exploiting weak random number generators in resource creation
• Leveraging information disclosure to discover valid resource IDs

Another common pattern involves HMAC-signed pagination tokens that contain object references:

// Vulnerable: HMAC token contains raw object references
function generatePageToken(userId, cursor) {
  const data = `${userId}:${cursor}`;
  return signWithHmac(data); // Only signs, doesn't verify ownership
}

// Attacker modifies userId in token
const maliciousToken = modifyUserIdInToken(validToken, '456');

The cryptographic integrity guarantees of HMAC become meaningless when the signed data includes identifiers the user shouldn't control. This is particularly problematic in microservices architectures where HMAC keys are distributed across services, each potentially implementing authorization checks differently or omitting them entirely.

Detecting BOLA/IDOR in HMAC-signed APIs requires understanding how these signatures are constructed and where authorization gaps exist. The key is to identify whether the HMAC verification process includes proper resource ownership validation.

Manual detection techniques include:

1. Capturing valid HMAC requests and systematically modifying resource identifiers
2. Testing with different user accounts to see if HMAC signatures from one account work for another's resources
3. Analyzing the HMAC input construction to see if user context is included
4. Checking if the HMAC key scope matches the authorization scope

Automated scanning with middleBrick specifically tests HMAC-signed endpoints by:

• Generating valid HMAC signatures for test requests
• Systematically replacing resource identifiers in signed requests
• Verifying whether modified requests are processed without proper authorization checks
• Checking if HMAC inputs include user context or resource ownership information

Here's what middleBrick's HMAC-specific BOLA/IDOR detection looks for:

// middleBrick analyzes HMAC signature construction
function analyzeHmacAuthorization(endpointSpec) {
  const hmacInputs = extractHmacInputs(endpointSpec);
  
  // Check if user context is included in HMAC
  const hasUserContext = hmacInputs.some(input => 
    input.includes('user_id') || input.includes('auth_context')
  );
  
  // Verify resource ownership validation exists
  const hasOwnershipCheck = endpointSpec.code.includes('verifyResourceOwnership') ||
                           endpointSpec.code.includes('checkPermissions');
  
  return {
    hmacVulnerability: !hasUserContext || !hasOwnershipCheck,
    severity: !hasUserContext ? 'critical' : 'high'
  };
}

Key indicators of HMAC BOLA/IDOR vulnerabilities:

middleBrick's scanning approach for HMAC APIs includes:

1. Signature generation using the API's documented HMAC algorithm
2. Resource ID enumeration and replacement attempts
3. Cross-user signature testing (using signatures from different authenticated users)
4. Analysis of HMAC input construction for missing authorization context

The scanner reports findings with specific remediation guidance, including whether the vulnerability stems from missing user context in HMAC inputs or absent ownership verification after signature validation.

Fixing BOLA/IDOR in HMAC-signed APIs requires both cryptographic and authorization improvements. The solution involves binding HMAC signatures to specific users and resources, then verifying ownership at the application level.

Remediation approach 1: Include user context in HMAC inputs

// Secure HMAC generation - includes user context
function generateSecureHmac(method, path, userId, timestamp, secretKey) {
  const hmac = crypto.createHmac('sha256', secretKey);
  
  // Include user ID and resource ID in signature
  const resourceId = extractResourceIdFromPath(path);
  const message = `${method}&${path}&${userId}&${resourceId}&${timestamp}`;
  
  hmac.update(message);
  return hmac.digest('base64');
}

// Verification includes user validation
function verifySecureHmac(req) {
  const { method, path, headers } = req;
  const { signature, timestamp, userId } = headers;
  
  // Verify HMAC first
  const expectedSignature = generateSecureHmac(method, path, userId, timestamp, secretKey);
  if (signature !== expectedSignature) {
    return false;
  }
  
  // Verify resource ownership
  const resourceId = extractResourceIdFromPath(path);
  return verifyUserOwnsResource(userId, resourceId);
}

Remediation approach 2: Use resource-specific HMAC keys

Instead of sharing keys across services, use keys scoped to user-resource combinations:

// Generate per-user, per-resource HMAC key
function generateUserResourceKey(userId, resourceId) {
  return crypto.createHash('sha256')
    .update(`${userId}:${resourceId}:hmac-salt`)
    .digest('base64');
}

// Each resource has unique key derivation
const userResourceKey = generateUserResourceKey(userId, resourceId);
const hmac = crypto.createHmac('sha256', userResourceKey);

Remediation approach 3: Implement authorization middleware

Always verify ownership after HMAC validation:

const authorizeResource = (req, res, next) => {
  const { userId } = req.user; // From authentication
  const resourceId = extractResourceId(req);
  
  // Check if user owns this resource
  if (!await verifyOwnership(userId, resourceId)) {
    return res.status(403).json({ error: 'Access denied' });
  }
  
  next();
};

// Apply to all resource endpoints
app.get('/api/users/:userId', authorizeResource, handleUserRequest);
app.get('/api/documents/:docId', authorizeResource, handleDocumentRequest);

Additional security measures:

1. Timestamp validation: Ensure HMAC signatures include recent timestamps to prevent replay attacks
2. Nonce implementation: Use nonces to prevent signature reuse
3. Scope limitation: Restrict HMAC keys to specific resource types or user roles
4. Audit logging: Log all HMAC verification failures and ownership check results

Testing the remediation involves:

• Verifying that modified resource IDs cause HMAC verification to fail
• Testing with different user accounts to ensure cross-account access is blocked
• Using tools like middleBrick to confirm BOLA/IDOR vulnerabilities are resolved

The key principle: HMAC signatures should bind requests to specific users and resources, and application logic must verify that the authenticated user has permission to access the requested resource. This dual-layer approach ensures both data integrity and proper authorization.