Practical Exercises

stride_analysis:
  spoofing:
    - endpoint: POST /api/auth/login
      threat: "Credential stuffing with leaked passwords"
      mitigation: "Rate limiting, MFA, breach detection"
    
    - endpoint: GET /api/tasks/:id/share
      threat: "Share links could be guessed or brute-forced"
      mitigation: "Use UUIDs, add authentication tokens"

  tampering:
    - endpoint: PUT /api/tasks/:id
      threat: "Modify task ID in request to change others' tasks"
      mitigation: "Server-side ownership verification"
    
    - endpoint: POST /api/users/:id/avatar
      threat: "Upload malicious file (XSS in SVG, webshell)"
      mitigation: "Validate file type, sanitize, serve from separate domain"

  repudiation:
    - endpoint: DELETE /api/tasks/:id
      threat: "No audit log - user claims they didn't delete task"
      mitigation: "Log all destructive operations with user ID, IP, timestamp"
    
    - endpoint: PUT /api/tasks/:id
      threat: "Changes not tracked - no history of modifications"
      mitigation: "Implement version history or change log"

  information_disclosure:
    - endpoint: GET /api/tasks
      threat: "API returns more fields than UI needs (over-fetching)"
      mitigation: "Use DTOs, only return necessary fields"
    
    - endpoint: POST /api/auth/login
      threat: "Different error messages reveal if email exists"
      mitigation: "Generic 'invalid credentials' message"

  denial_of_service:
    - endpoint: POST /api/auth/register
      threat: "Mass account creation depletes resources"
      mitigation: "CAPTCHA, rate limiting, email verification"
    
    - endpoint: POST /api/users/:id/avatar
      threat: "Upload huge files to fill storage"
      mitigation: "File size limits, quota per user"

  elevation_of_privilege:
    - endpoint: GET /api/tasks/:id
      threat: "IDOR - change task ID to access others' tasks"
      mitigation: "Verify task.owner_id == current_user.id"
    
    - endpoint: PUT /api/tasks/:id
      threat: "Modify task ownership via request body"
      mitigation: "Ignore owner_id in request, use authenticated user"

vulnerabilities = {
    'A - SQL Injection (Admin)': {
        'damage': 10,           # Full database access
        'reproducibility': 9,   # Reliable once found
        'exploitability': 5,    # Requires admin access first
        'affected_users': 10,   # All users' data at risk
        'discoverability': 3,   # Hidden behind admin auth
        'average': 7.4
    },
    'B - Stored XSS (Public)': {
        'damage': 6,            # Session hijacking, phishing
        'reproducibility': 10,  # Works every time
        'exploitability': 8,    # Easy to exploit
        'affected_users': 8,    # All visitors to that page
        'discoverability': 7,   # Scanner might find it
        'average': 7.8
    },
    'C - CSRF (Email Change)': {
        'damage': 7,            # Account takeover via password reset
        'reproducibility': 8,   # Needs user to click link
        'exploitability': 6,    # Moderate skill needed
        'affected_users': 4,    # Individual targets
        'discoverability': 5,   # Manual testing reveals
        'average': 6.0
    },
    'D - Sensitive URLs': {
        'damage': 5,            # Data exposure in logs
        'reproducibility': 10,  # Always logged
        'exploitability': 3,    # Need access to logs
        'affected_users': 6,    # Users who used that feature
        'discoverability': 4,   # Need to review logs
        'average': 5.6
    }
}

# Priority Order:
# 1. B - Stored XSS (7.8) - High impact, public-facing
# 2. A - SQL Injection (7.4) - Devastating but limited access
# 3. C - CSRF Email (6.0) - Targeted account takeover
# 4. D - Sensitive URLs (5.6) - Lower immediate risk

Reasoning:

• Stored XSS is prioritized because it's public-facing and affects all visitors
• SQL injection is severe but requires admin access first
• CSRF is targeted (one victim at a time)
• URL logging is a privacy concern but requires log access

Goal: Steal Credit Card Data
 OR
 |
 |-- [1] Compromise Web Application
 |   OR
 |   |-- [1.1] Exploit Application Vulnerability
 |   |   AND
 |   |   |-- Find RCE/SQLi vulnerability
 |   |   |-- Establish persistence
 |   |   |-- Access encrypted data
 |   |   |-- Obtain decryption key (see branch 3)
 |   |
 |   |-- [1.2] Steal Session Tokens
 |       AND
 |       |-- Inject XSS payload
 |       |-- Victim (admin) visits page
 |       |-- Exfil session cookie
 |       |-- Access admin panel
 |       |-- Export card data
 |
 |-- [2] Compromise Cloud Infrastructure
 |   OR
 |   |-- [2.1] Steal AWS Credentials
 |   |   OR
 |   |   |-- Find leaked keys in Git
 |   |   |-- Phish developer with AWS access
 |   |   |-- Exploit SSRF to access metadata service
 |   |
 |   |-- [2.2] Exploit Misconfiguration
 |       OR
 |       |-- Public S3 bucket with backups
 |       |-- Overly permissive IAM role
 |       |-- Unencrypted RDS snapshot
 |
 |-- [3] Obtain Encryption Keys
 |   OR
 |   |-- [3.1] Access AWS Secrets Manager
 |   |   AND
 |   |   |-- Obtain AWS credentials (see 2.1)
 |   |   |-- Have secretsmanager:GetSecretValue permission
 |   |
 |   |-- [3.2] Memory Dump
 |   |   AND
 |   |   |-- Get shell on application server
 |   |   |-- Dump process memory
 |   |   |-- Extract keys from memory
 |   |
 |   |-- [3.3] Social Engineering
 |       AND
 |       |-- Identify key custodian
 |       |-- Craft pretext (urgent audit, compliance)
 |       |-- Custodian shares access
 |
 |-- [4] Insider Threat
 |   OR
 |   |-- [4.1] Malicious Employee
 |   |   AND
 |   |   |-- Employee has database access
 |   |   |-- Employee has key access
 |   |   |-- Employee exports data
 |   |
 |   |-- [4.2] Compromised Employee
 |       AND
 |       |-- Target employee with access
 |       |-- Compromise their workstation (malware)
 |       |-- Pivot to internal systems
 |
 |-- [5] Third-Party Compromise
     AND
     |-- Payment processor is breached
     |-- Your transactions are in breach scope
     |-- Data includes your customers

Analysis:

• Critical control: AWS Secrets Manager access (appears in multiple paths)
• Cheapest path: Public S3 bucket (if misconfigured)
• Most likely: Phishing + credential theft chain
• Hardest to defend: Third-party compromise (limited control)

1. Data Flow Diagram

[User Browser] ---(1. username/password)---> [Auth Service]
                                                   |
                                           (2. generate code)
                                                   |
                                                   v
                                             [SMS Gateway]
                                                   |
                                           (3. SMS with code)
                                                   |
                                                   v
                                            [User's Phone]
                                                   |
[User Browser] <---(4. enter code)---
       |
       +--(5. code)---> [Auth Service] ---(verify)---> [Session Created]

2. STRIDE Analysis

3. DREAD Scoring

Threat: SIM Swap Attack
D: 8 (full account takeover)
R: 7 (carrier social engineering works)
E: 5 (requires research on target)
A: 3 (targeted individuals)
D: 6 (known attack vector)
Average: 5.8 - HIGH

Threat: Brute Force Code
D: 8 (account takeover)
R: 10 (deterministic)
E: 9 (simple script)
A: 10 (any user)
D: 8 (obvious attack)
Average: 9.0 - CRITICAL

Threat: Code Logged
D: 6 (insider access to accounts)
R: 10 (always logged if not prevented)
E: 3 (need log access)
A: 10 (all users)
D: 2 (need insider access)
Average: 6.2 - HIGH

4. Attack Tree: Bypass 2FA

Goal: Bypass SMS 2FA
 OR
 |-- Brute Force Code
 |   AND
 |   |-- Know username/password
 |   |-- No rate limiting
 |   |-- Try 1,000,000 combinations
 |
 |-- Intercept SMS
 |   OR
 |   |-- SIM Swap
 |   |   AND
 |   |   |-- Know target's phone number
 |   |   |-- Social engineer carrier
 |   |
 |   |-- SS7 Attack
 |   |   AND
 |   |   |-- Access to SS7 network
 |   |   |-- Intercept SMS in transit
 |   |
 |   |-- Malware on Phone
 |       AND
 |       |-- Trick user to install app
 |       |-- App has SMS permission
 |       |-- Exfil code to attacker
 |
 |-- Bypass Implementation
 |   OR
 |   |-- Race Condition
 |   |   AND
 |   |   |-- Submit code and change password simultaneously
 |   |   |-- 2FA check is skipped
 |   |
 |   |-- Predictable Codes
 |       AND
 |       |-- Weak random number generator
 |       |-- Predict next code
 |
 |-- Social Engineering
     AND
     |-- Call support as victim
     |-- Claim lost phone
     |-- Support disables 2FA

5. Mitigations

Gaps Found:

API Gateway (Kong):

• Missing: Spoofing (authentication bypass)
• Missing: Information Disclosure (verbose errors)
• Missing: Elevation of Privilege (admin API exposure)
• DoS "mitigated" is overconfident - rate limiting helps but doesn't prevent sophisticated attacks

Customer Service:

• Missing: Spoofing (JWT secret compromise)
• Missing: Repudiation (no audit logging mentioned)
• Missing: Information Disclosure (logs, error messages)
• Missing: DoS (no resource limits mentioned)
• Missing: EoP (container escape, RBAC)
• JWT alone doesn't prevent tampering of other data (database, files)

PostgreSQL:

• Missing: Spoofing (credential theft)
• Missing: Tampering (SQL injection from app)
• Missing: DoS (resource exhaustion, slow queries)
• Missing: EoP (database user privileges)
• Encryption at rest doesn't protect data in transit or from app-level access

Kubernetes-Specific Threats Not Addressed:

• Container escape / kernel exploits
• RBAC misconfiguration
• Secrets management (how are credentials stored?)
• Network policies (pod-to-pod communication)
• Image vulnerabilities
• Supply chain (base image trust)
• Node compromise
• etcd security
• Service account token abuse

Corrected Threat Model:

system: Customer API
components:
  - name: API Gateway (Kong)
    threats:
      - type: Spoofing
        description: "Authentication bypass via misconfigured plugins"
        status: needs_review
      - type: DoS
        description: "Volumetric attacks may exceed rate limits"
        status: partially_mitigated
        mitigation: "Rate limiting + WAF + CDN"
      - type: EoP
        description: "Admin API exposed to internet"
        status: open
        mitigation: "Bind admin to localhost, use NetworkPolicy"
  
  - name: Customer Service (Pod)
    threats:
      - type: Spoofing
        description: "JWT secret stored in Kubernetes Secret"
        status: needs_review
        mitigation: "Rotate secrets, use external secrets manager"
      - type: Repudiation
        description: "No structured audit logging"
        status: open
      - type: EoP
        description: "Container runs as root, no securityContext"
        status: open
        mitigation: "runAsNonRoot, drop capabilities, read-only rootfs"
  
  - name: PostgreSQL
    threats:
      - type: Information Disclosure
        description: "Encryption at rest enabled"
        status: mitigated
      - type: Information Disclosure  
        description: "Traffic between app and DB unencrypted"
        status: open
        mitigation: "Enable SSL, verify certificates"
      - type: Tampering
        description: "App uses parameterized queries"
        status: needs_verification
  
  - name: Kubernetes Cluster
    threats:
      - type: EoP
        description: "Default service accounts have cluster access"
        status: needs_review
      - type: Information Disclosure
        description: "etcd not encrypted"
        status: open