Week Content

Opening Framing: The Authorization Problem

Authentication verifies who you are. Authorization determines what you can do. Many applications nail authentication but fail catastrophically at authorization. They verify that you're logged in but don't verify that you should access the specific resource you're requesting.

Broken Access Control is #1 on the OWASP Top 10 for 2021— and for good reason. It's prevalent, impactful, and often trivial to exploit. Changing a user ID in a URL from your ID to another user's ID shouldn't reveal their data, but frequently it does.

This week covers access control vulnerabilities, Insecure Direct Object References (IDOR), privilege escalation, and the systematic approach to finding authorization flaws.

Key insight: Every request with a user-controlled identifier is a potential IDOR. Test them all.

1) Access Control Fundamentals

Understanding authorization models:

Access Control Types:

Vertical Access Control:
- Different user types have different privileges
- Admin vs. regular user
- Manager vs. employee
- Bypassing = privilege escalation

Horizontal Access Control:
- Same privilege level, different resources
- User A can't access User B's data
- Bypassing = IDOR

Context-Dependent Access Control:
- Access depends on state/workflow
- Can't skip steps in a process
- Can't access after deadline
- Bypassing = business logic flaws

Common Access Control Models:

Role-Based Access Control (RBAC):
- Users assigned to roles
- Roles have permissions
- Most common model

Permissions:
  Admin: read, write, delete, admin
  Editor: read, write
  Viewer: read

Attribute-Based Access Control (ABAC):
- Decisions based on attributes
- User attributes, resource attributes, environment
- More flexible, more complex

Example policy:
  IF user.department == resource.department
  AND user.clearance >= resource.classification
  THEN allow

Discretionary Access Control (DAC):
- Resource owner controls access
- Can share with others
- File system permissions

Mandatory Access Control (MAC):
- System enforces rules
- Users can't change permissions
- Military/government systems

Where Access Control Fails:

Common Failure Points:

1. Client-side only enforcement
   - JavaScript hides buttons
   - Server doesn't check

2. Security through obscurity
   - Long/random URLs
   - No actual access check

3. Inconsistent enforcement
   - GET endpoint protected
   - POST endpoint not protected

4. Missing checks on identifiers
   - User ID in URL not validated
   - Order ID accessible to anyone

5. Parameter manipulation
   - role=user → role=admin
   - isAdmin=false → isAdmin=true

6. Forced browsing
   - /admin accessible without login
   - API endpoints unprotected

Key insight: Access control must be enforced server-side, on every request, for every resource.

2) Insecure Direct Object References (IDOR)

The most common access control vulnerability:

IDOR Concept:

Application uses user-controlled input
to access objects directly:

/api/users/123/profile    → User 123's profile
/api/users/124/profile    → User 124's profile

If no authorization check:
Changing 123 → 124 reveals another user's data

IDOR = Direct reference + No authorization check

IDOR Locations:

URL Parameters:
/user?id=123
/profile/123
/api/v1/users/123
/download?file=report_123.pdf

POST/PUT Body:
{"user_id": 123, "action": "delete"}
{"account": "ACC123", "transfer": 1000}

Headers:
X-User-ID: 123
Cookie: user=123

File Names:
/documents/user_123_report.pdf
/uploads/invoice_123.pdf

API Endpoints:
GET /api/orders/ORD-123
DELETE /api/comments/456
PUT /api/profiles/789

Testing for IDOR:

Testing Methodology:

1. Create two test accounts
   - User A (attacker)
   - User B (victim)

2. Map all endpoints with identifiers
   - User IDs
   - Order IDs
   - Document IDs
   - Any reference

3. With User A's session:
   - Request User B's resources
   - Change ID parameters
   - Observe response

4. Check for:
   - Data disclosure (view other's data)
   - Modification (change other's data)
   - Deletion (remove other's data)

# Burp workflow:
1. Log in as User A
2. Capture request with User A's ID
3. Send to Repeater
4. Change to User B's ID
5. Does it return User B's data?

IDOR Variations:

# Sequential IDs (easiest)
/user/1, /user/2, /user/3
Enumerate all users

# UUIDs (harder but not secure!)
/user/550e8400-e29b-41d4-a716-446655440000
UUIDs are not secret if leaked anywhere

# Encoded IDs
/user/MTIz  → base64("123")
Decode, modify, re-encode

# Hashed IDs
/user/a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3
If hash is predictable (MD5 of sequential), enumerate

# Indirect references
/user/current → returns your data
/user/current?impersonate=123 → hidden parameter?

# Composite references
/org/1/user/123
Try: /org/2/user/123 (cross-tenant)

Key insight: Any identifier in a request is potentially vulnerable. UUIDs and encoding are not access control.

3) Privilege Escalation

Vertical access control bypass:

Privilege Escalation Types:

Vertical:
Regular user → Admin
Employee → Manager
Reader → Editor

Horizontal to Vertical:
Access another user's admin account
Access service account with higher privileges

Testing for Privilege Escalation:

# Access admin endpoints as regular user

1. Map admin functionality
   - Browse as admin, note URLs
   - /admin/*, /manage/*, /dashboard/*

2. Access as low-privilege user
   - Same URLs
   - Same API endpoints

# Common admin endpoints to test:
/admin
/admin/dashboard
/admin/users
/admin/settings
/api/admin/users
/api/v1/admin/*
/manage
/management
/console

# Use Burp:
1. Browse as admin, capture all requests
2. Log in as regular user
3. Replay admin requests with regular user's session
4. Check if access granted

Parameter-Based Privilege Escalation:

# Role/privilege in request

# Hidden form field:
<input type="hidden" name="role" value="user">
Change to: role=admin

# Cookie:
Cookie: role=user; session=abc123
Change to: role=admin

# JSON body:
{"username": "newuser", "role": "user"}
Change to: {"username": "newuser", "role": "admin"}

# JWT payload:
{"user": "john", "role": "user"}
Modify to: {"user": "john", "role": "admin"}
(if signature not validated)

# Query parameter:
/profile?admin=false
Change to: /profile?admin=true

# Header:
X-Admin: false
Change to: X-Admin: true

Function-Level Access Control:

# Different HTTP methods

# GET might be protected:
GET /admin/users → 403 Forbidden

# But POST isn't:
POST /admin/users → 200 OK (creates user!)

# API endpoints:
GET /api/users/123 → Your data only
DELETE /api/users/123 → Deletes any user!

# Test all methods:
GET, POST, PUT, PATCH, DELETE, OPTIONS

# Method override:
X-HTTP-Method-Override: DELETE
X-Method-Override: DELETE
_method=DELETE

Key insight: Just because you can't see admin functionality doesn't mean you can't access it directly.

4) Business Logic Flaws

Exploiting flawed application logic:

Business Logic vs Technical Vulnerabilities:

Technical: SQL injection, XSS
- Well-defined patterns
- Automated scanning helps

Business Logic: Flawed assumptions
- Application-specific
- Requires understanding the business
- Manual testing essential

Common Business Logic Flaws:

# Price Manipulation
Original: {"item": "laptop", "price": 999.99}
Modified: {"item": "laptop", "price": 0.01}

# Quantity Manipulation
Original: {"item": "gold", "quantity": 1}
Modified: {"item": "gold", "quantity": -10}
Result: Negative total = credit to account?

# Coupon/Discount Abuse
- Apply same coupon multiple times
- Apply coupon after checkout started
- Stack incompatible discounts

# Workflow Bypass
Normal: Step1 → Step2 → Step3 → Complete
Attack: Step1 → Step3 → Complete (skip verification)

# Race Conditions
- Submit same request simultaneously
- Withdraw money twice before balance updates
- Apply limited coupon multiple times

# State Manipulation
- Complete order, then cancel, keep items
- Upgrade trial, downgrade, keep features

Testing Business Logic:

Approach:

1. Understand the application
   - What does it do?
   - What are the workflows?
   - What are the rules?

2. Question assumptions
   - Can I skip steps?
   - Can I go backwards?
   - Can I do things out of order?
   - What if values are negative?
   - What if values are very large?

3. Test edge cases
   - Boundary values
   - Empty values
   - Unexpected types
   - Concurrent requests

4. Abuse features
   - Referral systems
   - Loyalty programs
   - Free trials
   - Promotional offers

Race Condition Testing:

# Race conditions in web apps

# Scenario: Limited coupon (100 uses)
# Attack: Send 100 concurrent requests

# Burp Turbo Intruder:
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=50,
                           requestsPerConnection=1,
                           pipeline=False)
    for i in range(100):
        engine.queue(target.req)

def handleResponse(req, interesting):
    if '200' in req.response:
        table.add(req)

# Or use Burp Repeater:
# Send to group, "Send group in parallel"

# What to test:
- Coupon redemption
- Money transfers
- Vote/like systems
- Limited inventory purchases
- Account balance operations

Key insight: Business logic testing requires thinking about what the application should do and finding ways to abuse it.

5) Automated IDOR Testing

Scaling access control testing:

Autorize Extension:

# Burp Autorize - automated authorization testing

Setup:
1. Install Autorize from BApp Store
2. Configure two sessions:
   - High-privilege (admin) cookies
   - Low-privilege (user) cookies

3. Browse as high-privilege user
4. Autorize replays requests with low-privilege session
5. Compares responses

Results:
🔴 Red = Access control bypassed (same response)
🟡 Yellow = Different response (investigate)
🟢 Green = Properly blocked

# Autorize catches:
- IDOR automatically
- Privilege escalation
- Missing authorization checks

Auth Analyzer Extension:

# Another Burp extension for auth testing

Features:
- Multiple session comparison
- Automatic detection of access control issues
- Good for complex role hierarchies

Setup:
1. Define sessions (admin, user, guest)
2. Browse application
3. Review flagged requests

Manual Automation with Intruder:

# Enumerate IDOR with Intruder

1. Capture request with ID parameter
   GET /api/users/123/profile

2. Mark ID as payload position:
   GET /api/users/§123§/profile

3. Payload: Numbers 1-1000
   Or known valid IDs

4. Attack and analyze:
   - Response length differences
   - Status codes
   - Interesting content

# Filter results:
- Remove your own ID
- Look for 200 responses
- Compare response sizes

Testing Checklist:

Access Control Testing Checklist:

□ Horizontal Access Control (IDOR)
  □ User IDs in URLs
  □ Resource IDs in API calls
  □ IDs in request bodies
  □ IDs in cookies/headers
  □ File references

□ Vertical Access Control
  □ Admin URLs as regular user
  □ Admin API endpoints
  □ Hidden parameters (role, admin)
  □ Method-based bypass (GET vs POST)

□ Context-Based
  □ Skip workflow steps
  □ Access after logout
  □ Access during restricted times
  □ Access from wrong state

□ Multi-Tenant
  □ Cross-organization access
  □ Tenant ID manipulation
  □ Shared resource access

□ API-Specific
  □ GraphQL authorization
  □ Batch operations
  □ Nested resource access

Key insight: Automation helps scale IDOR testing, but manual review catches what automation misses.

Real-World Context: Access Control in Practice

Access control vulnerabilities in the wild:

Bug Bounty Gold: IDOR is one of the most commonly reported and rewarded vulnerability types. Simple IDORs might earn $500-2000, while critical data exposure IDORs can earn $10,000+. The simplicity-to-impact ratio is excellent.

Real Breaches: Major data breaches have resulted from IDOR. Exposing millions of user records through a simple ID enumeration. API endpoints that never checked authorization. Admin panels accessible to any authenticated user.

Testing Challenges: Access control testing requires multiple accounts, understanding of business logic, and patience. It's hard to automate completely because valid access varies by context.

MITRE ATT&CK Mapping:

• T1078 - Valid Accounts: Using legitimate access inappropriately
• T1548 - Abuse Elevation Control: Privilege escalation
• T1530 - Data from Cloud Storage: Unauthorized data access

Key insight: IDOR is the "low-hanging fruit" that keeps giving. Applications consistently fail at authorization.

Guided Lab: IDOR and Access Control Testing

Practice access control testing on vulnerable applications.

Step 1: Setup Test Accounts

# Create two accounts on target application:
# - Account A (your "attacker" account)
# - Account B (your "victim" account)

# Note the IDs/identifiers for both accounts
# User IDs, profile URLs, etc.

Step 2: Map Endpoints with IDs

# Browse as Account A
# Note all URLs/requests containing identifiers:

/profile/123
/api/users/123
/orders/456
/documents/789

# Capture in Burp, categorize by resource type

Step 3: Test IDOR

# For each endpoint with ID:

1. Capture request as Account A
2. Note Account A's ID (e.g., 123)
3. Get Account B's ID (e.g., 124)
4. In Repeater, change 123 → 124
5. Send request
6. Check: Do you see Account B's data?

# Test multiple operations:
- View (GET)
- Modify (PUT/PATCH)
- Delete (DELETE)

Step 4: Test Privilege Escalation

# Find admin functionality
# (View page source, JavaScript files, documentation)

# Common admin paths:
/admin
/admin/dashboard
/api/admin/users
/manage

# Try accessing as regular user
# Try adding admin parameters:
?admin=true
?role=admin

Step 5: PortSwigger Labs

# Complete these labs:
# 1. Insecure direct object references
# 2. User ID controlled by request parameter
# 3. User role controlled by request parameter
# 4. URL-based access control can be circumvented
# 5. Method-based access control can be circumvented

# https://portswigger.net/web-security/access-control

Reflection (mandatory)

1. How many IDOR vulnerabilities did you find?
2. What type of data was exposed?
3. Were there any privilege escalation opportunities?
4. How would you recommend fixing these issues?

Week 07 Quiz

Test your understanding of Access Control, IDOR, and Business Logic Flaws.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Week 7 Outcome Check

By the end of this week, you should be able to:

• Understand access control models and common failures
• Identify and exploit IDOR vulnerabilities
• Test for vertical privilege escalation
• Find business logic flaws
• Use automated tools for access control testing
• Apply systematic methodology to authorization testing

Next week: Injection Beyond SQL—command injection, LDAP, XML, and other injection attacks.

🎯 Hands-On Labs (Free & Essential)

Apply what you learned through practical access control testing exercises. Complete these labs before moving to reading resources.

💡 Lab Strategy: Start with PortSwigger for comprehensive coverage of all access control vulnerability types. Then use TryHackMe for IDOR-specific practice, PentesterLab for advanced scenarios, and Juice Shop to test your discovery skills. Remember: always test with multiple user accounts! 750 total XP, 9-13 hours of training on the #1 OWASP vulnerability!

🛡️ Defensive Architecture & Secure Design Patterns

Authorization must be enforced on every request. Defensive architecture centralizes access checks, minimizes trust in client-provided IDs, and verifies ownership server-side.

RBAC/ABAC and Centralized Enforcement

Best practices:
- Use server-side authorization middleware
- Default deny for all endpoints
- Enforce ownership checks on every object
- Avoid client-side role flags entirely

Authorization Matrix:

Define per-role permissions:
Role   | Read Own | Read Others | Update Own | Update Others | Admin
User   |   Yes    |     No      |    Yes     |      No       |  No
Manager|   Yes    |   Limited   |    Yes     |    Limited    |  No
Admin  |   Yes    |    Yes      |    Yes     |     Yes       |  Yes

Real-World Incidents: Facebook/Meta Access Control Bugs

Multiple incidents have exposed user data through IDOR-like flaws in APIs and GraphQL endpoints. Lessons learned: enforce object-level authorization in every resolver, validate tenant boundaries, and log unauthorized access attempts.

Defensive Labs

📚 Building on CSY101 Week-13: Threat model authorization boundaries and abuse cases. CSY101 Week-14: Map controls to NIST 800-53 (AC) and CIS Controls. CSY104 Week-11: Use CVSS to prioritize access control remediation.

Reading Resources (Free + Authoritative)

Complete the required resources to build your foundation.

• PortSwigger - Access Control · 60-90 min · 50 XP · Resource ID: csy203_w7_r1 (Required)
• OWASP Authorization Cheat Sheet · 30-45 min · 50 XP · Resource ID: csy203_w7_r2 (Required)
• PortSwigger - Business Logic Vulnerabilities · Reference · 25 XP · Resource ID: csy203_w7_r3 (Optional)

Lab: Comprehensive Access Control Assessment

Goal: Perform complete authorization testing from IDOR to privilege escalation.

Part 1: Reconnaissance

1. Create multiple test accounts (2-3)
2. Map all endpoints containing identifiers
3. Document user roles and permissions
4. Identify admin functionality

Part 2: IDOR Testing

1. Test all ID parameters for horizontal access
2. Test sequential ID enumeration
3. Test encoded/hashed ID manipulation
4. Document all unauthorized data access

Part 3: Privilege Escalation

1. Access admin endpoints as regular user
2. Test role parameter manipulation
3. Test HTTP method override
4. Test function-level access control

Part 4: Business Logic

1. Identify key business workflows
2. Test step-skipping
3. Test parameter manipulation (price, quantity)
4. Test race conditions if applicable

Part 5: Automation

1. Configure Autorize extension
2. Run automated authorization testing
3. Review and validate findings

Deliverable (submit):

• Endpoint/ID inventory
• IDOR vulnerability documentation
• Privilege escalation findings
• Business logic flaw report
• Remediation recommendations

Checkpoint Questions

1. What is the difference between horizontal and vertical access control?
2. What makes a direct object reference "insecure"?
3. Why are UUIDs not sufficient for access control?
4. How do you test for privilege escalation?
5. What is a business logic flaw?
6. How does the Autorize Burp extension help with access control testing?

Weekly Reflection

Reflection Prompt (200-300 words):

This week you learned access control testing—finding authorization flaws that let you access data and functionality you shouldn't. You exploited IDORs and tested privilege escalation.

Reflect on these questions:

• IDOR is conceptually simple—just change an ID. Why do developers continue to make this mistake?
• Access control requires checking authorization on EVERY request. What development practices could help ensure this?
• Business logic flaws are application-specific. How do you approach testing an application you've never seen?
• You tested with multiple accounts. What challenges arise when testing access control with only one account?

A strong reflection will connect technical vulnerabilities to development practices and testing methodology.

Verified Resources & Videos

• Autorize: Autorize Burp Extension
• IDOR Testing: HackTricks IDOR
• Business Logic: OWASP Business Logic Testing

Access control vulnerabilities remain the #1 web application risk because authorization is hard to get right. Every resource, every endpoint, every action needs proper checks. The IDOR and privilege escalation techniques you've learned will find vulnerabilities in almost every application you test. Next week: injection attacks beyond SQL.