IDOR Vulnerability in Banner Deletion

How it was found

Summary

I found an IDOR vulnerability in Revive Adserver's banner deletion endpoint that lets any Manager delete banners belonging to other Managers. The code validates access to the parent campaign but doesn't check if the user owns the specific banner being deleted. This means Manager A can sabotage Manager B's ad campaigns by deleting their banners.

Description

The /www/admin/banner-delete.php endpoint is vulnerable to Insecure Direct Object Reference (IDOR). When I tested it, I could delete another manager's banners by manipulating the bannerid parameter while keeping my own valid clientid and campaignid.

Here's what happens: The endpoint checks if I have access to the client and campaign (lines 30-31), but it never verifies I own the specific banner I'm trying to delete (missing check at line 32). The code then loops through the provided banner IDs and deletes them without any ownership validation (lines 40-48).

I discovered this while comparing similar deletion endpoints. The campaign-delete.php file properly validates ownership inside the loop, but banner-delete.php doesn't.

Steps to Reproduce

Prerequisites

• Two Manager accounts (Manager A - attacker, Manager B - victim)
• Each manager has their own client, campaign, and banners
• Revive Adserver 6.0.1 running

Exploitation Steps

1. Login as Manager A (attacker)
   • Navigate to http://localhost:8080/www/admin/
   • Login with Manager A credentials

{F4938082}

Manager A successfully authenticated and viewing dashboard

2. Navigate to your campaign's banner page

   http://localhost:8080/www/admin/campaign-banners.php?clientid=100&campaignid=100
   

   (Use your own clientid and campaignid)

{F4938090}

Manager A viewing their legitimate banner - note the CSRF token in the Deactivate link

3. Extract CSRF token

   • Open browser DevTools → Network tab
   • Look for any action link (Deactivate/Delete)
   • Copy the token parameter value (32-character hex string)
   • Example: token=9fec0e8e46e9eb237d67d3da6e3e615b

4. Identify victim's banner ID

   • Banner IDs are sequential integers
   • You can enumerate them or get them through other means
   • For this test: victim's banner ID is 2001

5. Craft malicious deletion URL

   http://localhost:8080/www/admin/banner-delete.php?token=<YOUR_TOKEN>&clientid=100&campaignid=100&bannerid=2001
   

   • token: Your valid CSRF token (from step 3)
   • clientid=100: YOUR client ID (passes authorization check)
   • campaignid=100: YOUR campaign ID (passes authorization check)
   • bannerid=2001: VICTIM's banner ID (NO check!)

6. Execute the attack

   • Paste the crafted URL into your browser's address bar
   • Press Enter (within the same session)
   • You'll get redirected with a "Banner has been deleted" confirmation

{F4938094}

CRITICAL: Green success message confirms Manager B's banner was deleted by Manager A

Impact

This vulnerability allows horizontal privilege escalation between managers. Here's what an attacker can do:

1. Campaign Sabotage - Delete competitors' banners to disrupt their ad campaigns
2. Revenue Loss - Victims lose active advertisements and potential revenue
3. Reputation Damage - Affected clients may lose trust in the platform
4. Data Integrity Violation - Unauthorized deletion bypasses audit controls

Attack Characteristics

• Low Privilege Required: Only needs a Manager account (not Admin)
• Easy to Exploit: Simple parameter manipulation, no special tools needed
• Stealthy: Looks like a legitimate deletion in logs
• Scalable: Can be automated to delete multiple banners
• Cross-Context: Manager in Agency X can attack Manager in Agency Y